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1.  GENEKAL  INFORMATION 


1.1  PURPOSE  OF  THIS  DOCUMENT 

This  document  records  current  agreements  on  implementation  details  of  OSI 
protocols  among  the  organizations  participating  in  the  NBS/OSI  Workshop  Series 
for  Implementors  of  OSI  Protocols.  These  decisions  are  documented  to 
facilitate  organizations  in  their  understanding  of  the  status  of  agreements. 
This  is  a standing  document  that  is  intended  to  be  updated  after  each  workshop 
(about  every  2-1/2  months). 

1.2  PURPOSE  OF  THE  WORKSHOP 

In  February,  1983  NBS  organized  the  above  named  workshop  to  bring  together 
future  users  and  potential  suppliers  of  OSI  protocols.  The  workshop  accepts 
as  input  the  specifications  of  emerging  standards  for  protocols  and  produces 
as  output  agreements  on  the  implementation  and  testing  particulars  of  these 
protocols.  This  process  is  expected  to  expedite  the  development  of  OSI 
protocols  and  promote  interoperability  of  independently  manufactured  data 
communications  equipment. 

1.3  PET  ATIONSHIPS  OF  WORKSHOPS  TO  EVENTS  AND  ACTIVITIES 

The  workshop  is  held  for  those  organizations  expressing  an  interest  in 
implementing  OSI  protocols.  However,  there  is  no  corporate  commitment  to 
implementations  associated  with  workshop  participation.  Other  events  stem 
from  the  workshop  to  which  commitments  are  attached.  Sixteen  organizations 
did  make  formal  commitments  to  implement  and  demonstrate  some  of  the  protocols 
at  the  1984  National  Computer  Conference.  Commitments  were  made  by  General 
Motors,  Boeing  Computer  Services,  and  21  vendors  to  demonstrate,  at  AUTOFACT 
1985,  a set  of  OSI  protocols  known  as  the  Manufacturing  Automation  Protocol 
or  MAP  specification.  This  event  was  an  outgrowth  of  the  workshop  in  that  the 
implementation  decisions  reached  in  the  workshops  were  used  for  the  AUTOFACT 
demonstration.  However,  the  AUTOFACT  demonstration  was  planned  and  carried 
out  by  GM,  BCS,  and  suppliers  they  selected.  This  event  had  no  further 
affiliation  with  the  workshop. 

A different  activity,  initiated  by  NBS,  is  the  OSINET,  which  is  to  be  a long 
standing,  globally  distributed  network  that  is  put  in  place  for  purposes  such 
as  test  methods  development  and  testing  of  prototype  implementations. 
Presently,  25  organizations  have  committed  to  participate.  As  with  the 
AUTOFACT  demonstration,  protocols  used  on  OSINET  are  those  agreed  to  in  the 
workshop.  Also,  as  with  the  AUTOFACT  demonstration,  the  OSINET  has  no  other 
affiliation  with  the  workshop.  Unlike  the  AUTOFACT  demonstration,  however, 
OSINET  participation  is  open  to  any  organization  committing  to  the  OSINET 
agreements . 
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1.4  RELATIONSHIP  OF  THE  WORKSHOP  TO  THE  NBS  LABORATORIES 


As  resources  permit,  NBS,  with  voluntary  assistance  from  industry,  develops 
formal  protocol  specifications,  reference  implementations,  tests  and  test 
systems  for  the  protocols  agreed  to  in  the  workshops.  This  is  work  made 
available  to  the  industry  volunteers  and  to  others  making  valid  commitments  to 
organized  events  and  activities  such  as  NCC,  AUTOFACT,  and  OSINET.  As  soon 
as  this  work  can  be  adequately  documented  it  is  placed  in  the  public  domain 
through  submission  to  the  National  Technical  Information  Service.  Any 
organization  may  then  obtain  the  work  at  nominal  charge. 

The  NBS  laboratories  bear  no  other  relationship  to  the  workshop. 

1.5  STRUCTURE  AND  OPERATION  OF  THE  WORKSHOP 


1.5.1  Plenary 

The  main  body  of  the  workshop  is  a plenary  assembly.  Any  organization  may 
participate.  Representation  is  international.  NBS  prefers  for  the  business 
of  workshops  to  be  conducted  informally,  since  there  are  no  corresponding 
formal  commitments  within  the  workshop  by  participants  to  implement  the 
decisions  reached.  The  guidelines  we  follow  are:  1)  one  vote  per  company  or 

independent  division,  2)  only  companies  that  regularly  attend  should  vote,  3) 
only  companies  that  plan  to  sell  or  buy  a protocol  should  vote  on  its 
implementation  decisions,  4)  only  companies  knowledgeable  of  the  issues  should 
vote,  and  5)  no  proxy  votes  are  admissible. 

1.5.2  Special  Interest  Groups 

Within  the  workshop  there  are  Special  Interest  Groups  (SIGs).  The  SIGs  receive 
their  instructions  for  their  technical  program  of  work  from  the  plenary.  The 
SIGs  meet  independently,  usually  during  the  workshop.  As  technical  work  is 
completed  by  a SIG,  it  is  presented  to  the  plenary  for  disposition.  Companies 
participating  in  a SIG  are  expected  to  participate  in  the  plenary.  Voting 
rules  for  SIGS  are  the  same  as  voting  rules  for  the  plenary. 

Special  Interest  Groups  sometimes  correspond  with  organizations  performing 
related  work,  such  as  ANSI  committees.  Such  correspondence  should  be  sent 
through  the  plenary  to  the  parent  committee,  such  as  ANSC  X3T5  or  ANSC  X3S3 . 
When  SIG  meetings  take  place  between  workshops,  the  correspondence  from  these 
meetings  should  be  addressed  directly  to  the  parent  committee  and  copied  to 
the  workshop  plenary. 

Following  are  procedures  for  cooperative  work  among  Special  Interest  Groups. 

o Any  SIG  (SIG  1)  or  individual  having  issues  to  discuss  with  or 
requirements  of  another  SIG  (SIG  2)  should  bring  the  matter  to 
the  attention  of  the  chairperson  of  that  SIG  (SIG  2). 
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o The  SIG  2 chairperson  should  bring  the  matter  before  SIG  2 for 
action. 

o SIG  2 should  respond  to  the  concerns  or  needs  of  SIG  1 or  the 
individual  in  a timely  manner. 

o If  the  matter  cannot  be  satisfactorily  resolved  or  if  the 
request  is  outside  the  charter  assigned  to  SIG  1,  then  it  should 
be  brought  before  the  plenary. 

o SIGs  are  expected  to  complete  work  in  a timely  manner  and  bring 
the  results  before  the  plenary  for  disposition.  However,  the 
plenary  may  elect  to  act  on  any  issue  within  the  scope  of  the 
workshop  at  any  time. 

Following  are  the  charters  of  the  the  nine  Special  Interest  Groups. 

FTAMSIG 


Develop  phase  2 product-level  specifications. 

Future  new  work  items  will  be  defined  in  a Phase  3 specification.  It  will 
contain  only  extensions  of  Phase  2 FTAM.  It  is  a goal  that  Phase  3 will  be 
backward  compatible  with  Phase  2 FTAM.  The  set  of  future  work  items  listed 
below  may  be  changed  by  the  plenary  if  the  work  is  more  appropriate  for  other 
SIGs. 

High  priority  work  items: 

o Clean  up  section  10  of  this  document 
o Specify  Reliable  File  Service 

o Specify  Recovery  and  Restart  Data  Transfer  functional  units 
in  the  user  correctable  file  service 

o Specify  concurrency  control  parameter. 

Low  priority  work  items: 

o Add  new  document  types/constraint  sets 

o Define  subset  of  authorization  requirements 

o Specify  Presentation  Context  Management  functional  unit. 

X. 400  SIG 


Develop  product- level  specifications  for  Message  Handling  Systems  using  the 
CCITT  X.400  Recommendations. 

Develop  abstract  tests  for  X.400,  as  requested  by  the  ad  hoc  rapporteur  for 
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this  study  question  in  CCITT.  This  work  is  to  be  submitted  by  the  plenary 
(after  its  approval)  to  The  U.S.  Department  of  State  as  a proposed  U.S. 
contribution  to  CCITT  Study  Group  VII. 

Lower  Layer  SIG 

The  Lower  Layer  SIG  will  study  OSI  layers  1-4  and  produce  recommendations  for 
implementations  to  support  the  projects  undertaken  by  the  workshop  and  the 
work  of  the  other  SIGs.  Both  connectionless  and  connection-oriented  modes  of 
operation  will  be  studied.  The  SIG  will  accept  direction  from  the  plenary  for 
work  undertaken  and  the  priority  which  it  is  assigned. 

The  objectives  of  the  Lower  Layer  SIG  are: 

o Study  OSI  layers  1-4  as  directed  by  the  plenary, 

o Produce  and  maintain  recommendations  for  implementation  of  these 
layers , 

o Where  necessary,  provide  input  to  the  relevant  standards  bodies 
concerning  layers  1-4,  in  the  proper  manner,  and 

o Begin  work  on  the  implementation  specification  of  the  ISO  Network 
Layer  Routing  Exchange  Protocol  prior  to  the  ISO  draft  achieving  DIS 
status . 

Performance  SIG 

The  plenary  will  provide  the  following  inputs  to  the  OSI  Performance  SIG: 

o the  set  of  applications  for  which  the  performance  of  OSI 
protocols  is  of  particular  concern, 

o the  requirements  for  each  application  including: 

- performance  targets 

- network  topology 

- background  network  loads 

- application  traffic  characteristics,  and 

o this  document,  "Implementation  Agreements  Among 
Implementors  of  OSI  Protocols". 

The  objectives  of  the  OSI  Performance  SIG  are  to: 

o determine  whether  the  OSI  protocols  are  able  to  meet 
these  performance  requirements, 

o report  these  determinations  to  the  plenary,  and 
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o where  appropriate,  provide  input  to  the  voluntary  standards 
bodies  concerning  changes  to  existing  standards  and  the 
requirements  for  new  ones,  in  the  appropriate  form. 

OSI  Security  Architecture  SIG 

GOAL:  To  develop  an  overall  OSI  Security  Architecture  which  is  consistent 

with  the  OSI  and  which  economically  satisfies  the  primary  security 
needs  of  both  the  commercial  and  Government  sectors. 

APPROACH:  To  define  a security  architecture  encompassing  the  security  addenda 

presently  being  specified  at  certain  OSI  layers,  the  required 
cryptographic  algorithms  and  related  key  management  functions,  and 
the  security  management  functions  which  must  be  performed  between 
the  layers  and  the  peer  entitities  defined  in  the  OSI  architecture. 

Directory  Services  SIG 

Produce  functional  implementation  agreements  based  on  ISO/CCITT  specifications 
for  Directory  Services  in  accordance  with  the  objectives  and  goals  of  the 
plenary. 

o Provide  a subset  for  NBS  publication  which  is  functional  and  forward 
compatible  to  further  work  by  this  Special  Interest  Group. 

o Define  stable  core  functionality  which,  can  be  implemented  in  the  near 
term. 

Virtual  Terminal  SIG 


This  Special  Interest  Group's  charter  is  based  upon  the  implementation  of 
Draft  International  Standards  9040  and  9041  and  their  respective  addenda,  in 
providing  Basic  Virtual  Terminal  Service. 

This  group  will  develop  agreements  for  the  implementation  and  testing  of  the 
following  terminal  types. 


o X. 29  PAD 
o TELNET 
o Basic  Scrolling 
o Basic  Paging 
o Basic  Forms 
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Upper  Layers  SIG 


Develop  product- level  specifications  for  the  implementation  of  Session  service 
and  protocol.  Presentation  service  and  protocol,  and  ACSE  service  and 
protocol.  These  specifications  will  be  developed  to  support  the  application 
layer  services  FTAM,  X.400,  VT,  and  Directory  Services.  In  addition,  the  SIG 
is  responsible  for  requirements  in  common  between  Multiple  Application 
services,  for  example,  registration  of  Application  Contexts  and  Abstract 
Syntaxes . 

Office  Document  Architecture  and  Office  Document  Interchange  Format  SIG 

Develop  product-level  specifications  for  the  architecture  and  interchange  of 
office  documents  processed  by  computers.  The  standard  governing  the  ODA/ODIF 
SIG's  work  is  ISO  8613  - Office  Document  Architecture  (ODA)  and  Interchange 
Format  (ODIF). 


1.6  POINTS  OF  CONTACT 


OSI  Workshop  - General 
OSI  Workshop  - Registration 

FTAM  SIG 
X.400  SIG 
Lower  Layers  SIG 
Performance  SIG 
Security  SIG 
DS  SIG 
VT  SIG 

Upper  Layers  SIG 
ODA/ODIF  SIG 
MAP 
TOP 

Government  OSI  Spec. 

OSINET 

Steering  Committee 
Technical  Committee 
SME  (MAP/TOP  Sponsorship) 


John  Heafner,  NBS,  301/975-3618 
Mary  Lou  Fahey,  NBS,  301/975-3600 
Joan  Wyrwa,  NBS,  301/975-3643 
Rick  Peterson,  GM,  313/947-0586 
John  Stidd,  Xerox,  408/737-4338 
Kevin  Miles,  DEC,  +44-734-868711 
Mary  Jane  Strohl,  CDS, 617/460-0808 
Denny  Branstad,  NBS,  301/975-2913 
J.  J.  Cinecoe,  WANG,  617/967-5514 
TBD 

Mike  Ellis,  HP,  916/786-8000x4292 
TBD 

Gary  Workman,  GM,  313/947-0599 
Laurie  Bride,  BCS,  206/763-5719 
John  Heafner,  NBS,  301/975-3618 

TBD 

Ed  Strum,  IBM,  415/855-7392 
Mark  Shaw,  313/271-1500 
Paul  Borawski,  313/271-1500 
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2.  THE  PROTOCOLS 


The  selected  protocols  for  which  implementation  agreements  have  been  made  and 
are  being  developed  are: 

o IEEE  802.2  Logical  Link  Control 
o IEEE  802.3  CSMA/CD  Access  Method 
o IEEE  802.4  Token  Bus  Access  Method 
o CCITT  Recommendation  X.25 
o Private  Subnetworks 

o Network  Dependent  Convergence  Sublayer  Protocol  between  X.25  and  ISO 
Connectionless  IP 

o X.25  Packet  Layer  Protocol  to  support  the  Connection  Oriented  Network 
Service 

o ISO  Connectionless  Internetwork  Protocol 

o ISO  Transport  Classes  4 and  0 and  Connectionless  Protocols 
o ISO  Session  Protocol 

o ISO  File  Transfer,  Access  and  Management  Protocol 
o ISO  Presentation  Layer  Protocol 
o ISO  CASE  Protocol 

o CCITT  400  Series  Recommendations  for  Message  Handling  Facility 
o CCITT  and  ISO  Directory  Services  Protocol 

Reference  documents  and  sources  for  obtaining  them  are  given  under  References. 
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3.  LOCAL  AREA  NETWORKS 


3 . 1  IEEE  802.2  LOGICAL  LINK  CONTROL 


The  following  decisions  have  been  reached  with  respect  to  this  protocol. 

1.  Link  Service  Access  Point  (LSAP) 


The  IEEE  802  committee  has  assigned  the  code  below  to  address  systems  using 
ISO  IS  8473  connectionless  network  protocols.  Note  that  bit  zero  is 
transmitted  first. 

The  most  significant  bit  is  bit  7,  thus  this  bit  .pattern  represents 
hexadecimal  FE. 


0 

1 

2 

3 

4 

5 

6 

7 

0 

1 

1 

1 

1 

1 

1 

1 

Fig.  3.1  LSAP  bit  pattern 


2.  Type  and  Class 

Only  the  connectionless  type  1,  class  1 IEEE  802  link  service  will  be  used. 

3.  Exchange  Identification  and  Test 

The  Exchange  Identification  (XID)  and  Test  (TEST)  will  not  be  sent.  If  one  is 
received  it  will  be  discarded. 

3.2  IEEE  802.3  CSMA/CD  ACCESS  METHOD 

The  48  bit  addressing  will  be  used  with  the  10  megabit/second  baseband  coaxial 
cable  specification. 

3 . 3 IEEE  802.4  TOKEN  BUS  ACCESS  METHOD 


The  following  options  are  agreed  to  with  respect  to  Draft  F of  token  bus.  An 
asterisk  means  that  the  option  has  been  approved.  The  absence  of  an  asterisk 
means  that  the  option  has  not  been  approved. 

1.  Repeaters 

Active  Regenerative 

2.  Medium 

Single  Cable  Coax  * 

Dual  Cable  Coax 
3 o Trunk  Cable 

RG-6  * 

RG-11  * 
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Semi-rigid 

X 

Other  75  ohm  cables 

* 

4. 

Trunk  Connection  Unit 

75  ohm  tee  connector 
75  ohm  nondirectional  passive 
impedence-matching  tap 

75  ohm  directional  passive  impedence- 
matching  tap 

* 

5. 

Transmit  Carrier  Frequency 

RF 

Baseband 

* 

6. 

Modulation 

Phase  Continuous  FSK 
Phase  Coherent  FSK 

AM/PSK 

* 

7 . 

Encoding 

Manchester 

Duobinary 

* 

8. 

Data  Rate 
1 Mb 

5 Mb 

* 

10  Mb 

* 

9. 

Addressing 

2 octet 

6 octet 

* 

10. 

Connector  at  Station 

50  ohm  Male  BNC  Series 

75  ohm  Female  F Series 

* 

11. 

Priority  (4  levels) 

* 

12. 

Group  Addressing 

* 

13. 

Station  Management 

14. 

Broadband  Channel  Assignments 

Forward 

P 

Q 

R 

S 

T 

U 


Reverse 


3 1 * 

4«  * 

4M'  * 

5'  * 

6'  * 


FM1 ' 
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4.  WIDE  AREA  NETWORKS 


4.1  CCITT  RECOMMENDATION  X.25 

When  providing  CONS,  it  is  agreed  to  use  X.25  as  the  standard  wide  area 
network  protocol.  Elements  of  X.25  are  explained  in  section  6.2.2. 


5.  PRIVATE  SUBNETWORKS 

5.1  PRIVATE  SUBNETWORKS 


The  architectures  agreed  upon  allow  the  use  of  private  subnetworks  in  addition 
to  private  X.25  subnetworks.  No  particular  private  subnetwork  has  been 
discussed. 
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6.  NETWORK  LAYER 


6.1  CONNECTIONLESS  NETWORK  SERVICE  (CLNS) 

6.1.1  Provisions  of  CLNS  using  CLNP  (IS  8473) 

The  following  decisions  have  been  reached  with  respect  to  this  protocol. 

o The  "Protocol  for  providing  the  connection- less  service,"  ISO  IS 
8473,  will  be  used  to  provide  the  CLNS. 

o The  non -segmenting  and  the  inactive  subsets  will  not  be 

supported. 

6.1.2  Agreements  on  Protocol  Functions 

o For  purposes  of  demonstration  the  value  to  be  used  to  bound  the 
maximum  lifetime  of  the  internetwork  protocol  data  unit  is  three 
times  the  network  span.  The  span  of  the  network  is  considered 
to  be  the  number  of  intermediate  systems  between  source  and 
destination  plus  the  destination  end  system. 

o For  purposes  of  testing,  intermediate  and  end  systems  will  log 
the  following  conditions: 

o Discarded  protocol  data  units, 

o Error  protocol  data  units  (recorded  by  system  generating 
the  error  PDU),  and 

o Detection  of  protocol  data  units  containing  unsupported 
type  3 options. 

6.1.3  Agreements  on  Optional  Protocol  Functions 

o The  security  parameter  will  not  be  used. 

o Intermediate  systems  should  recognize  and  support  both  complete 
and  partial  source  routing. 

Although  end  systems  may  implement  source  routing  (of  either 
type),  any  requirement  for  end  system  source  routing  is  deferred 
for  future  study,  since  support  for  it  may  be  related  to  layer 
management  protocols. 

o Partial  source  routing  will  be  supported  by  intermediate 
systems.  The  destination  should  log  the  route,  if  possible. 

o The  ISO  specification  will  be  followed  with  respect  to  quality 
of  service. 


11 


o For  purposes  of  testing,  checksums  will  be  turned  on  and  used. 

In  operation  this  is  a local  decision. 

6.1.4  Network  Dependent  Convergence  Sublayer  Function  (CLNS  Over  X.25) 

A network  dependent  convergence  sublayer  protocol  operating  between  CCITT 
Recommendation  X.25  and  the  ISO  Connectionless  IP  has  been  agreed  to.  It 
shall  adhere  to  the  following. 

o Follow  ISO  8473  DAD1  (N3601)  Working  Paper  for  the  SNDCF 
framework. 

o Only  initiate  one  SVC  for  all  outbound  PDUs  to  any  other  given 
intermediate  system  or  PDN  end  system.  Note:  this  results  in  at 
most  two  SVCs  between  any  pair  of  systems. 

o Open  a connection  upon  demand. 

o Disconnect  SVCs  by  administrative  request  and  a finite  timeout 
timer. 

o Use  the  default  throughput  class. 

o Do  not  use  D-bit  or  Q-bit. 

o Negotiate  window  size  according  to  ISO  IS  8208.  A default  of 
window  size  two  must  be  supported. 

o Negotiate  packet  size  according  to  ISO  IS  8208.  A default  of 
128  octets /packet  must  be  supported. 

o The  SNDCF  will  "advertise"  support  for  SNSDUs  up  to  IK  via  the 
X.25  M-bit  facility. 

o No  statistics  gathering  is  required  beyond  that  which  the  CLNS 
may  gather  for  the  X.25  packet  layer  or  for  SNDCF  entities. 

6.2  CONNECTION  MODE  NETWORK  SERVICE  (CONS) 


There  is  interest  among  a limited  set  of  participants  in  implementing  the 
connection  mode  network  service.  This  section  records  the  agreement  of  the 
workshop  on  the  provision  of  a connection  mode  network  service. 

6.2.1  Introduction 

The  X.25  Packet  Level  Protocol  (PLP)  is  used  to  provide  the  OSI 
Connection-mode  Network  Service  (CONS).  This  proposal  is  independent  of  lower 
and  higher  layer  protocol  considerations,  which  are  also  discussed  briefly 
herein. 

When  providing  the  CONS,  the  following  shall  apply: 
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o The  definition  of  the  CONS  is  as  specified  in  ISO  8348,  "Network 
Service  Definition"; 

o The  mapping  of  the  elements  of  the  CONS  to  the  elements  of  the 
X.25/PLP  is  as  specified  in  ISO  8878,  "Use  of  X.25  to  Provide 
the  OSI  Connection-mode  Network  Service";  and 

o The  general  procedures  and  formats  of  the  X.25/PLP  are  as 
specified  in  ISO  8208,  "X.25  Packet  Level  Protocol  for  Data 

Terminal  Equipment".  Note  that  this  standard  provides  for  the 
use  of  the  X.25/PLP  in  environments  in  addition  to  an  X.25 
PSPDN,  such  as  point-to-point  topologies  as  well  as  LANs.  (The 
details  of  how  to  use  the  X.25/PLP  in  LANs  are  given  in  ISO 
8881,  "Information  Processing  Systems  - Data  Communications  - 
Use  Of  The  X.25  Packet  Level  Protocol  in  Local  Area  Networks.") 

6.2.2.  Provision  of  CONS  Using  X.25/PLP 

The  provision  of  the  CONS  using  the  X.25/PLP  is  as  described  in  the  second 
bullet  above.  This  section  provides  a brief  description  taken  directly  from 
ISO  8878;  for  more  detail,  see  ISO  8878. 

Also  note  that  the  X. 25/PLP-1984  is  capable  of  supporting  the  full  CONS, 
including  quality-of-service  (QOS)  aspects.  The  X. 25/PLP-1984  shall  be  used 
in  LANS  and  in  packet -switched  networks  allowing  the  use  of  the  elements  of 
the  X. 25/PLP-1984  needed  to  support  the  CONS.  In  other 

packet-switched-network  environments,  a Subnetwork  Dependent  Convergence 
Protocol  (SNDCP)  shall  be  used  in  conjunction  with  the  X. 25/PLP-1980  (see 
section  6.2.5). 

6 . 2 . 2 . 1 Overview 


6.2.2. 1.1  Elements  of  the  X.25/PLP  for  Support  of  the  CONS 

The  table  below  lists  the  packets  and  associated  fields  used  when  supporting 
the  OSI  CONS. 
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Tbl.  6.1  Packets  and  fields  of  X.25/PLP  used  to  support  OSI  CONS 


PACKET  TYPES1 

FIELDS2 

CALL  REQUEST 
INCOMING  CALL 
CALL  ACCEPTED 
CALL  CONNECTED 

Facility  Field,  Call  and 
Called  User  Data  Field 

CLEAR  REQUEST 
CLEAR  INDICATION 

Clearing  Cause  Code  Field, 
Diagnostic  Code  Field, 
Facility  Field,  Clear  User 
Data  Field 

DATA 

M-Bit,  User  Data  Field 

RESET  REQUEST 
RESET  INDICATION 

Resetting  Cause  Code 
Field,  Diagnostic  Code 
Field 

RESTART  INDICATION 

Restarting  Cause  Code 
Field, 

Diagnostic  Code  Field 

Notes : 

1.  The  packets  shown  in  the  table  are  used  in  support  of  the 
primitives  of  the  OSI  CONS.  Other  packets  not  shown  in  the 
table  (i.e.,  CLEAR  CONFIRMATION,  RESET  CONFIRMATION,  and  RESTART 
CONFIRMATION  packets)  are  essential  to  the  use  of  the  packets 
shown.  Yet  other  packets  (i.e.,  RESTART  REQUEST,  DIAGNOSTIC, 
REGISTRATION  REQUEST,  and  REGISTRATION  CONFIRMATION  packets) 
have  no  relationship  to  the  provision  of  the  OSI  CONS. 

In  line  with  these  agreements,  the  INTERRRUPT,  INTERRUPT 
CONFIRMATION,  RECEIVE  READY,  RECEIVE  NOT  READY,  and  REJECT 
packets  are  not  needed  to  support  the  OSI  CONS  because  the 
corresponding  aspects  of  the  OSI  CONS  are  not  to  be  used  (i.e., 
the  Expedited  Data  Transfer  Service  and  the  Receipt  Confirmation 
Service  are  not  used).  However,  the  RECEIVE  READY  and  RECEIVE 
NOT  READY  packets  are  needed  for  the  proper  operation  of  the 
X.25/PLP. 
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2.  The  information  in  the  fields  shown  in  the  table  has  a direct 
relationship  to  the  parameters  associated  with  the  primitives  of 
the  OSI  CONS.  Other  fields  not  shown  in  the  table  (e.g.,  the 
Logical  Channel  Identifier,  the  Packet  Type  Identifier,  the 
Address  Length  Fields  and  the  Facility  Length  Field)  are 
essential  to  the  use  of  the  appropriate  packets. 

In  addition,  it  is  also  necessary  for  the  following  optional  user  facilities 
and  CCITT-Specif ied  DTE  Facilities  to  be  used  and/or  agreed  to: 

1.  optional  user  facilities 

o Fast  Select  (facility  used) 

o Fast  Select  Acceptance  (facility  agreed  to,  if  operating  in  a 
packet- switched  network  environment) 
o Throughput  Class  Negotiation  (facility  agreed  to  and 
used),  and 

o Transit  Delay  Selection  And  Indication  (facility  used); 

Note:  When  operating  in  a DTE-to-DTE  environment  without  an  intervening 

packet-switched  network,  the  use  of  the  Fast  Select  Facility  must  also 
be  agreed  to  by  the  two  DTEs.  In  addition,  the  Fast  Select  Acceptance 
Facility  does  not  apply. 

2.  CCITT-Specif ied  DTE  facilities 

o Called  Address  Extension  (facility  used), 
o Calling  Address  Extension  (facility  used), 
o End-to-End  Transit  Delay  Negotiation  (facility  used), 
o Expedited  Data  Negotiation  (facility  used),  and 
o Minimum  Throughput  Class  Negotiation  (facility  used). 

Elements  of  the  X.25/PLP  not  needed  in  support  of  the  CONS  are: 

o Q-bit 

o Permanent  Virtual  Circuits  (PVCs), 
o Diagnostic  packets,  and 

o optional  user  facilities  other  than  those  listed  above. 

Elements  of  the  X.25/PLP  not  used  within  the  scope  of  these  agreements  are: 

o D-bit  and 
o INTERRRUPT  packets . 

6.2.2. 1.2  General  Operation  of  X. 25/PLP-1984  for  Supporting  OSI  CONS 

The  X.25/PLP  can  be  used  to  provide  the  OSI  CONS  in  an  end  system  connected  to 
a public  or  private  X.25  packet-switched  network  environment.  It  can  also  be 
used  in  environments  where  the  end-system  is  connected  to  a local  area  network 
or  where  end  systems  are  connected  by  a dedicated  path  or  by  a 
circuit-switched  connection. 
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The  NS  provider  (more  particularly,  the  Network  Layer  (NL)  entity  in  an 
end-system)  must  provide  a translation  between 

1.  the  primitives  and  parameters  of  the  OSI  CONS;  and 

2.  the  packets  and  associated  fields  of  the  X.25/PLP. 

Request  and  response  primitives  are  translated  into  packets  to  be  transmitted 
across  the  DTE/DCE  interface  by  the  NL  entity.  Received  packets,  where 
appropriate,  are  translated  by  the  NL  entity  into  indication  and  confirm 
primitives.  These  translations  are  shown  in  sections  6. 2. 2. 2 through  6.2.2. 7. 

Note:  The  Network  Service  Definition  specifies  valid  sequences  of  primitives 

at  a NC  endpoint  and  valid  parameter  responses  at  the  called  NC 
endpoint  to  Receipt  Confirmation  negotiation.  Expedited  Data 
negotiation,  and  QOS  parameter  negotiation.  The  necessity  for  the  NL 
entity  to  police  compliance  and  the  NL  entity  actions  to  be  taken  on 
non-compliance  are  a local  matter  and  not  subject  to  standardization. 

There  is  also  a relationship  between  some  local  mechanism  used  to  identify  a 
particular  Network  Connection  (NC)  and  a Logical  Channel  (LC)  number  used  to 
identify  a particular  virtual  circuit.  This  relationship  is  a local  matter. 

6. 2. 2. 2 Network  Connection  Establishment  Phase 


Table  6.2  shows  the  relationships  between  the  primitives/parameters  used 
during  the  Network  Connection  Establishment  Phase  and  the  packets/ fields 
associated  with  the  Call  Setup  Procedures. 
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Tbl.  6.2  CONS:  X.25/PLP  mapping  for  the  network  connection 
establishment  phase 


CONS 

X.  25/PLP-1984 

PRIMITIVES : 

PACKETS: 

N- CONNECT  request 

CALL  REQUEST 

N-CONNECT  indication 

INCOMING  CALL 

N-CONNECT  response 

CALL  ACCEPTED 

N-CONNECT  confirm 

CALL  CONNECTED 

PARAMETERS : 

FIELDS  (INCLUDING  FACILITIES): 

Called  Address 

Called  Address  Extension  Facility 

Calling  Address 

Calling  Address  Extension 
Facility 

Responding  Address 

Called  Address  Extension  Facility 

Receipt  Confirmation 

See  Note  1. 

Selection 

Expedited  Data  Selection 

See  Note  1 . 

QOS  Parameter  Set 

Throughput  Class  Negotiation 
Facility^ 

Minimum  Throughput  Class 
Negotiation  Facility 
Transit  Delay  Selection  And 
Indication  Facility 
End-to-End  Transit  Delay 
Negotiation  Facility 

NS-User-Data 

Call  and  Called  User  Data  Field 
Fast  Select  Facility^ 

Notes  to  table  6.2: 


1.  Within  the  scope  of  these  agreements,  the  Receipt  Confirmation 
Service  and  Expedited  Data  Service  will  not  be  used.  Therefore, 
the  Network  Service  provider  will  indicate  the  unavailability  of 
these  services  even  if  requested  by  the  Network  Service  user.  To 
do  this  does  not  require  an  explicit  protocol  mechanism. 
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2.  For  proper  operation,  this  optional  user  facility  must  also  be 
agreed  to  for  use  on  the  interface. 

3.  For  proper  operation,  the  Fast  Select  Acceptance  Facility  must 
also  be  agreed  to  on  the  interface  when  accessing  a 
packet-switched  network. 

6. 2. 2. 3 Network  Connection  Release  Phase 


Table  6.3  shows  the  relationships  between  the  primitives/parameters  used 
during  the  Network  Connection  Release  Phase  and  the  packets/f ields  associated 
with  the  Call  Clearing  Procedures. 

Tbl.  6.3  CONS:  X.25/PLP  mapping  for  network  connection  release 

phase 


CONS 

X. 25/PLP-1984 

PRIMITIVES: 

PACKETS : 

9 

N-DISCONNECT  request 
N-DISCONNECT  indication 

CLEAR  REQUEST 
CLEAR  INDICATION, 
RESTART  INDICATION1, 
CLEAR  REQUEST2 

PARAMETERS : 

FIELDS  (INCLUDING  FACILITIES): 

Originator  and  Reason 

Cause  Code  and  Diagnostic  Code 
Fields2 

NS -User-Data 

Clear  User  Data 

Responding  Address 

Called  Address  Extension  Facility 

Notes  to  Table  6.3: 

1.  Receipt  of  a RESTART  INDICATION  packet  should  be  treated  as 
receipt  of  a CLEAR  INDICATION  packet  for  every  logical  channel 
and  then  mapped  to  an  N-DISCONNECT  indication  primitive  for 
every  active  NC  associated  with  the  Packet  Level  Protocol  being 
restarted.  The  Restarting  Cause  Code  and  Diagnostic  Code  Fields 
are  then  treated  in  the  same  manner  as  the  Clearing  Cause  Code 
and  Diagnostic  Code  Fields. 

2.  Used  only  when  the  NL  entity  in  the  end  system  originates  an 
N-DISCONNECT  indication  primitive. 
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3.  The  combination  of  Cause  Code  and  Diagnostic  Fields  is  mapped 
to/ from  the  combination  of  Originator  and  Reason  parameters. 
Where  the  IS  8208  diagnostic  codes  are  not  provided,  all 
Cause/Diagnostic  code  combinations  can  be  mapped  to  the 
Orignator/Reason  parameter  values  of  "Undefined". 

6 .2.2.4  Data  Transfer  Phase  --  Data  Transfer  Service 


Table  6.4  shows  the  relationships  between  the  primitives/parameters  used  for 
the  Data  Transfer  Service  and  the  packets/f ields  associated  with  the  Data 
Transfer  Procedures. 

Tbl.  6,4  CONS:  X.25/PLP  mapping  for  the  data  transfer  service 


CONS 

X. 25/PLP-1984 

PRIMITIVES : 

PACKETS : 

N-DATA  request 

DATA 

N-DATA  indication 

DATA 

PARAMETERS : 

FIELDS: 

NS-User-Data 

User  Data,  M-bit 

Confirmation  Request 

See  Note  1 . 

Note  to  table  6.4: 


1.  Since  the  Receipt  Confirmation  Service  is  not  to  be  provided,  a 
Confirmation  Request  is  not  valid. 

6. 2. 2. 5  Data  Transfer  Phase  --  Receipt  Confirmation  Service 

This  service  is  not  provided  by  these  agreements. 


6. 2. 2. 6  Data  Transfer  Phase  --  Expedited  Data  Transfer  Service 
This  service  is  not  provided  by  these  agreements. 


6. 2. 2. 7  Data  Transfer  Phase  --  Reset  Service 


Table  6.5  shows  the  relationships  between  the  primitives/parameters  used  for 
the  Reset  Service  and  the  packets/f ields  associated  with  the  Reset  Procedures. 
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Tbl.  6.5  CONS:  X.25/PLP  mapping  for  the  reset  service 


CONS 

X. 25/PLP-1984 

PRIMITIVES : 

PACKETS : 

N-RESET  request 
N-RESET  indication 
N-RESET  response 
N-RESET  confirm 

RESET  REQUEST 

RESET  INDICATION,  RESET  REQUEST1 

none 

none 

PARMETERS: 

FIELDS : 

Originator  and  Reason 

Cause  Code  and  Diagnostic  Code 
Fields^ 

Notes  to  table  6.5: 

1.  Used  only  when  the  NL  entity  in  the  end  system  originates  an 
N-RESET  indication  primitive. 

2.  The  combination  of  Cause  Code  and  Diagnostic  Code  Fields  is 
mapped  to/from  the  combination  of  Originator  and  Reason 
parameters.  Where  the  IS  8208  diagnostic  codes  are  not 
provided,  all  Cause/Diagnostic  code  combinations  can  be  mapped 
to  the  Originator/Reason  parameter  values  of  "Undefined". 

6.2.3  Requirements  for  Underlying  Layer 

As  cited  in  IS  8208,  the  X.25/PLP  requires  the  following  of  the 
underlying  Layer  2: 

o low  duplication  rate, 

o low  missequencing  rate, 

o low  undetected  bit-error  rate,  and 

o low  loss  rate. 

When  operating  in  a packet-switched  (X.25)  network  environment,  the  underlying 
LAPB  protocol  ensures  these  requirements.  When  operating  in  a LAN 

environment,  LLC  1 can  be  used.  Considerations  for  LLC  1 are  given  in  DP  8881. 

6.2.4  Consideration  of  OSI  Transport  Layer  Protocol  Class 

It  may  be  useful  to  explore  the  desirability  of  an  alternative  to  the 
Transport  Class  4 protocol  for  use  over  the  CONS.  See  section  7,  Transport. 

6.2.5  Subnetwork  Dependent  Convergence  Protocol 

In  cases  where  an  end  system  is  required  not  to  use  the  elements  of  the 
X.  25/PLP-1984  needed  to  support  the  OSI  CONS  (e.g.,  when  operating  in  .i 
packet-switched  network  environment  that  will  treat  as  an  error  the  use  of  anv 
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of  the  CCITT-specif ied  DTE  facilities),  then  it  shall  use  a Subnetwork 
Dependent  Convergence  Protocol  (SNDCP)  to  provide  the  necessary  elements  of 
the  OSI  CONS  to  the  Network  Service  user.  These  elements  involve  certain 
aspects  of  the  Network  Connection  Establishment  Phase  and  the  Network 
Connection  Release  Phase. 

The  SNDCP  to  be  used  is  referred  to  as  the  Alternative  Procedures  for  Network 
Connection  Establishment  and  Release  in  DP8878.  The  procedures  for  the  data 
transfer  phase  of  the  SNDCP,  as  specified  in  DP8878,  are  essentially  the  same 
as  those  in  sections  6. 2. 2. 4 through  6. 2. 2. 7 of  this  document. 

6.2.5. 1 Network  Connection  Establishment  Phase 


The  procedures  for  this  phase  are  as  specified  in  DP8878,  Annex  A,  Section 
6.1(b)  (the  Alternative  Network  Connection  Establishment  Procedure).  These 
procedures  use: 

o A CALL  REQUEST  packet  containing  (in  addition  to  the  packet 
header,  the  Address  Fields,  and  other  facilities): 

the  Throughput  Class  Negotiation  Facility  if  available; 
otherwise,  the  throughput  of  the  virtual  circuit  must  be  known  a 
priori  (by  way  of  the  Default  Throughput  Classes  Assignment 
Facility,  for  example),  and 

- a Call  User  Data  Field  containing  three  octets:  a one-octet 
Protocol  ID  identifying  the  X.25/PLP-1980  SNDCP  encoded  X' 84' 

(as  assigned  by  ISO)  and  a two-octet  Continuation  Parameter 
encoded  X'2D00'  to  indicate  the  first  M-bit  sequence  (MBS)  of 
DATA  packets  will  contain  additional  Network  Connection  (NC) 
Establishment  parameters; 

o A CALL  ACCEPTED  packet  with  necessary  information  for  proper 
X.25  subnetwork  interface  operation  but  without  any  NC 
Establishment  parameters; 

o An  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 

sent  by  the  originator  of  the  NC  Establishment  attempt, 
containing  all  necessary  NC  Establishment  parameters  encoded 
according  to  DP8878,  Annex  A,  Section  8.7(c)  (This  MBS  is  known 
as  an  N-CR  message.);  and 

o An  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 

sent  by  the  recipient  of  the  NC  Establishment  attempt  (assuming 
NC  acceptance),  containing  all  necessary  NC  Establishment 
parameters  encoded  according  to  DP8878,  Annex  A,  Section  8.7(d) 

(This  MBS  is  known  as  an  N-CC  message.);  see  section  6. 2. 5. 2 for 
NC  refusal. 

The  transit  delay  of  each  subnetwork  must  be  estimated. 

Similar  to  the  use  of  the  X. 25/PLP-1984m  the  following  items  are  to  be  noted: 
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o The  Network  Service  provider  will  indicate  the  unavailability, 
during  NC  Establishment,  of  the  Receipt  Confirmation  Service  and 
the  Expedited  Data  Service;  therefore,  no  protocol  mechanisms 
are  necessary  for  the  negotiation  of  these  services;  and 

o NSAP  Addresses  are  carried  entirely  in  the  Address  Extension 
Fields  of  the  N-CR  and  N-CC  messages. 

A Connect  Response  Timer  may  be  used  as  specified  in  DP8878,  Annex  A,  Section 
6.8(a). 
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Figure  6.1  shows  the  NC  Establishment  Phase. 


N- CONNECT 
REQUEST 


N- CONNECT 
CONFIRM 


CALL  REQUEST/ 

INCOMING  CALL 

CALL  ACCEPTED/ 

CALL  CONNECTED/ 

> 1 DATA  WITH  N-CR 


> 1 DATA  WITH  N-CC 


N- CONNECT 
INDICATION 


N- CONNECT 
RESPONSE 


Fig.  6.1  Successful  NC  establishment 
6. 2.5. 2 Network  Connection  Release  Phase 


The  procedures  for  this  phase  are  as  specified  in  DP8878,  Annex  A,  Section  6.2 
(b)  (the  Alternative  Network  Connection  Release  Procedure).  These  procedures 
are  also  used  to  refuse  an  NC  establishment  attempt.  These  procedures  use: 

o An  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 
sent  by  the  originator  of  the  NC  release,  containing  all 
necessary  NC  Release  parameters  encoded  according  to  DP8878, 

Annex  A,  Section  8.8(a)  (This  MBS  is  known  as  an  N-DR  message 
and  serves  as  an  "invitation  to  clear,"  that  is,  initiate  X.25 
clearing  procedures  to  the  recipient.);  and 

o The  X.25  CLEAR  REQUEST/ INDICATION  packet  as  indicated  in 
DP8878,  Annex  A,  Section  8.8(b). 

The  above  procedures  apply  to  NC  release  when  initiated  by  the  Network  Service 
user.  When  initiated  by  the  NS  provider,  the  N-DR  message  will  not  be  sent 
but  the  Originator  and  Reason  parameter  values  shall  both  be  "undefined." 

A Disconnect  Response  Timer  may  be  used  per  DP8878,  Annex  A,  Section  6.8(b). 

Figure  6.2  shows  the  NC  Release  Phase. 

6. 2. 5. 3 Data  Transfer  Phase  - Data  Transfer  Service 


The  Data  Transfer  Service  for  the  X. 25/PLP-1980  SNDCP  is  the  same  as  for  the 
X. 25/PLP-1984  procedures,  see  section  6. 2. 2. 4 of  this  document. 
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6. 2. 5. 4 Data  Transfer  Phase  - Receipt  Confirmation  Service 


As  for  the  X. 25/PLP-1984  procedures,  this  service  is  not  provided  by  these 
agreements . 

6 .2. 5. 5 Data  Transfer  Phase  - Expedited  Data  Transfer  Service 

As  for  the  X. 25/PLP-1984  procedures,  this  service  is  not  provided  by  these 
agreements . 

6 .2  <,5. 6 Data  Transfer  Phase  - Reset  Service 


The  Reset  Service  for  the  X. 25/PLP-1980  SNDCP  is  the  same  as  for  the 
X. 25/PLP-1984  procedures,  see  section  6. 2. 2. 7 of  this  document. 
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N-CONNECT 

REQUEST 


N-DISCONNECT 

INDICATION 


CALL  REQUEST/ 

INCOMING  CALL 

> 1 CALL  ACCEPTED/ 
CALL  CONNECTED 
> DATA  WITH  N-CR  


> 1 DATA  WITH  N-DR 


CLEAR  REQUEST/ 

CLEAR  INDICATION 


N-CONNECT 

INDICATION 

N-DISCONNECT 

REQUEST 


(a)  NC  ESTABLISHMENT  REFUSAL 


NORMAL  DATA 
>1  DATA  WITH  N-DR 


N-DISCONNECT 

REQUEST 


N-DISCONNECT 

INDICATION 


CLEAR  REQUEST/ 
CLEAR  INDICATION 


(b)  NC  RELEASE  AFTER  DATA  TRANSFER 
Fig.  6.2  NC  release 


6.2.6  Interworking 

Interworking  between  subnetworks  needs  to  be  specified.  The  principles  of  the 
Internal  Organization  of  the  Network  Layer,  DP  8648,  need  to  be  addressed.  A 
generalization  of  these  principles  for  the  OSI  CONS  case  is  shown  in  Figure 
6.3. 
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' 

- Routing  and  Relaying  - 

X.  25 

X.  25 

PLP* 

PLP* 

Layer  2 

Layer  2 

Protocol 

Protocol 

Layer  1 

Layer  1 

Protocol 

Protocol 

*This  can  be  either  X.  25/PLP-1984  or  X. 25/PLP-1980  with  an  SNDCP,  see  section 

6.2.5. 

Fig.  6.3  Generalized  interworking  for  OSI  CONS 

The  detailed  behavior  and  properties  of  the  Interworking  Unit  are  to  be 
specified  in  future  extensions  of  this  document.  DP  8881  and  DP  8878  discuss 
various  aspects  of  interworking. 

6.3  ADDRESSING  AND  ROUTING  CRITERIA 

The  following  have  been  agreed  to. 

o Do  not  go  beyond  ISO  routing  standardization  efforts. 

o Keep  the  end  system  as  simple  as  possible.  Put  the  needed 

complexity  into  the  intermediate  systems.  Minimize  memory 
overhead  and  enhance  performance  in  the  end  systems . 

o Addressing  and  routing  decisions  should  include  the  NBS  OSINET 
that  permits  inclusion  of  private  subnetworks  and  end  systems  on 
PDNs . 

o Permit  multiple  subnetwork  (alternate  paths)  in  a single 
intermediate  system. 

o Allow  expandability  for  additional  functionality  beyond  that 
required  for  a specific  demonstration. 

o Support  a certain  minimal  topology.  Accommodate  multiple  LANs, 

WANs,  and  private  subnetworks. 
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o Facilitate  efficient  implementation  of  intermediate  systems. 
Minimize  memory  overhead  and  enhance  performance  of  intermediate 
systems . 

o The  OSINET  will  accommodate  end  systems  attached  directly  to 
PDNs  as  one  requirement. 


6.4  GENERAL  ADDRESSING  AND  ROUTING  PRINCIPLES 


The  following  have  been  agreed  to. 

1.  Support  DAD2.  This  supports  criterion  no.  1. 

2.  Routing  Management 
Static  Routing: 

All  end  systems  and  intermediate  systems  will  provide  a local 
mechanism  to  manipulate  (and  optionally  create)  the  local 
routing  table.  Consistency  checking,  configuration,  and 

updating  of  a local  table  with  all  other  tables  will  be 
performed  by  human  operators.  The  lack  of  flexibility  induced 
by  static  procedures  can  be  minimized  with  the  use  of  the 
following  aids: 

o alternate  static  routes 
o route  update  utility 
o FTAM  route  table  distribution 
o table  format  via  X.409  (ASN-1)  encoding. 

Dynamic  Routing: 

Endsys tern- Intermediate  System  - A standard  that  provides  the 
functionality  of  dynamic  routing  must  be  provided.  The  protocol 
(see  references),  Item  ISO  18,  "Network  Layer  Management 
Protocol...",  provides  for  this  functionality  between  end  and 
intermediate  systems.  This  standard  is  expected  to  be  endorsed 
(and  appropriate  implementor  agreements  drafted)  to  provide  this 
function  at  a time  when  it  reaches  the  draft  proposal  status. 

Intermediate  system- Intermediate  System 

To  be  determined. 
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3.  Routing  Principles 

The  algorithm  and  data  structures  used  for  routing  are  not 
specified  by  this  document.  Implementors  are  free  to  perform 
these  functions  in  the  manner  which  is  most  appropriate  for 
their  system  environment.  However,  all  implementations  must 
have  the  following  characteristics: 

o end- systems 

End-systems  must  recognize  a destination  address  on  a directly 
connected  subnet  and  send  the  NPDU  to  the  destination  system. 
When  an  NPDU  is  destined  to  a system  that  is  not  on  a directly 
connected  subnet,  the  NPDU  must  be  sent  to  an  intermediate 

system  for  further  routing.  The  end  system  may,  but  is  not 
required  to,  choose  the  intermediate  system  used  on  the  basis  of 
the  destination  subnet. 

o intermediate  systems 

For  static  routing,  intermediate  systems  must  recognize  all 
assigned  subnetwork  addresses  and  route  NPDU's  in  the  following 
way:  If  an  NPDU  is  destined  to  an  end  system  which  is  connected 

to  the  same  subnet  as  the  intermediate  system,  the  NPDU  is  sent 
directly  to  the  end  system.  If  an  NPDU  is  destined  to  an  end 
system  which  is  not  connected  to  the  same  subnet  as  the 

intermediate  system,  the  NPDU  is  sent  to  an  appropriate 

intermediate  system  for  further  routing.  If  an  NPDU  is  destined 
to  an  end  system  on  an  unknown  subnet,  the  NPDU  is  discarded. 
If  the  error  flag  is  set,  an  error  NPDU  is  sent  to  the  source 
address  specified  in  the  errant  NPDU. 

4.  There  is  a single  NSAP  selector  for  each  NSAP  within  an  end 
system.  For  each  end  system  NSAP,  one  and  only  one  NSAP  address 
will  be  used  to  identify  the  NSAP.  This  conforms  to  the 
requirements  of  DAD2  and  supports  criterion  no.  1 to  comply  with 
current  ISO  standards. 

5.  Hierarchical  NSAP  addressing  should  be  used  to  minimize  the  size 
of  routing  tables.  This  conforms  to  criterion  no.  9. 

6.  The  NSAP  address  used  at  the  network  service  interface  is  based 
on  one  and  only  one  subnetwork  point  of  attachment  (SNPA).  This 
makes  the  hierarchial  addressing  more  specific  and  implies  that 
subnetwork  specific  addressing  information  is  embedded  in  the 
NSAP  address. 
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7. 


The  encoded  network  protocol  address  information  (NPAI)  conveyed 
in  the  IPDU  representing  an  NSAP  address  contains  an  encoded 
subnetwork  address  corresponding  to  the  selected  SNPA.  This 
makes  hierarchical  addressing  more  specific  as  applied  to 
addressing  formats.  The  embedding  of  the  subnetwork  address 
facilitates  routing  and  simplifies  routing  tables. 

8.  The  workshop  participants  require  control  over  the  DSP  encoding 
of  the  NSAP  address. 

9.  NBS  has  obtained  an  IDI  with  value  4 from  ISO  for  OSINET  so  that 
the  AFI  encoding  "47"  may  be  used. 

10.  Optionally,  the  NSAP  addressing  format  should  be  able  to  support 
multiple  network  layer  user  entities,  e.g.,  transport  entities, 
within  one  end  system. 

11.  All  of  the  above  principles  lead  to  the  address  format  agreed 
upon  and  shown  below. 

While  one  address  format  is  explicitly  specified  in  these 
agreements  (Fig.  6.4),  this  address  format  is  not  meant  to 
preclude  the  support  for  other  ISO  standardized  NSAP  address 
formats. 


47 

ISO 

NBS 

PORTION  OF  DSP  DEFINED 

IDI 

ASSIGNED 

ASSIGNED  BY  INDIVIDUAL 

ORGANIZATIONAL 

ORGANIZATION  ADDRESSING 

I.D. 

AUTHORITIES 

12  2 <11 


Fig.  6.4  NSAP  address  format 

12.  If  used  in  the  DSP,  an  NSAP  Selector  field  is  not  used  for 
routing  purposes  nor  for  locating  the  end  system.  It  only 
locates  the  network  layer  user  entity  within  the  end  system 
attached  through  the  addressed  NSAP. 

13.  In  order  to  fulfill  the  criteria  in  section  6.3,  item  3,  a 

standard  that  provides  the  functionality  of  dynamic  routing  must 
be  provided.  The  protocol  referenced  under  ISO,  item  // 18 
"Network  Layer  Management  Protocol  ..."  provides  for  this 
functionality  between  end  and  intermediate  systems.  This 

standard  is  expected  to  be  endorsed  to  provide  this  function  at 
a time  when  it  reaches  draft  proposal  status. 
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7.  TRANSPORT 


These  agreements  support  the  integration  of  LANs,  packet  networks,  and  other 
WANs  with  the  smallest  possible  set  of  mandatory  protocol  sets,  in  accordance 
with  the  other  agreements  already  reached.  Nothing  here  shall  preclude 
vendors  from  implementing  protocol  suites  in  addition  to  the  ones  described  in 
this  document.  Two  connection  oriented  transport  classes  have  been 
identified  for  implementation  (class  0 and  class  4).  In  addition,  there  is 
interest  among  a limited  set  of  participants  in  implementing  a connectionless 
transport  protocol.  Transport  class  4 (over  CLNP)  has  been  endorsed  for 
general  communication  between  private  systems.  Transport  class  0 (over  X.25) 
is  used  for  communication  with  public  (i.e.,  PT&T  and  RPOA)  MHS  systems 
operating  in  accordance  with  the  CCITT  X.400  series  Recommendations. 
Communicating  entities  between  private  MHS  systems  over  an  X.25  network  can, 
by  negotiation  or  bilateral  agreement,  agree  to  use  transport  class  0.  The 
connectionless  transport  protocol  can  be  used  with  transaction-type 
implementations . 

7.1  TRANSPORT  CLASS  4 


7.1.1  Transport  Class 

The  following  agreement  has  been  reached  with  respect  to  this  protocol. 

Class  4 will  be  used  with  the  required  implementation  of  the  31  bit  sequence 
space  and  16  bit  window  size.  The  full  protocol  will  be  used  including 
expedited  data  and  negotiation  at  connection  establishment. 

7.1.2  Protocol  Interpretation 

According  to  the  ISO  transport  specification,  a disconnect  request  is  issued 
in  response  to  a connect  request  when  the  maximum  number  of  transport 
connections  is  reached  or  exceeded. 

7.1.3  Rules  for  Negotiation 

o In  general,  the  ISO  rules  for  negotiation  will  be  used, 
specifics  follow. 

o All  implementations  will  send  the  16/31  window  size/sequence 
space  in  the  CR  TPDU.  Implementations  must  all  provide  the 
16/31  ISO  option.  Implementations  must  be  able  to  accept  the 
4/7  in  CR  TPDU. 
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o The  ISO  TPDU  size  is  128  to  8K  octets,  always  negotiated 
downward.  The  ISO  rules  are  to  be  followed,  allowing  any  valid 
size  in  the  CR  TPDU.  TPDU  size  negotiation  is  a local 
implementation  issue.  Each  vendor  will  decide  how  it  is 
implemented  in  their  end  system. 

o The  security  parameter  is  optional  and  user  defined  in  the  ISO 
specification.  Implementations  should  not  send  the  security 
parameter  in  the  CR  TPDU;  if  received  it  should  be  ignored. 

o Both  transports  must  agree  to  not  use  checksum,  according  to  the 
ISO  specifications.  Requesting  its  use  is  an  implementation 
choice.  All  implementations  must  be  able  to  operate  with 
checksum  if  requested. 

o Use  of  acknowledgement  time  parameter  is  optional  in  ISO  8073. 
If  an  implementation  is  operating  any  policy  which  delays  the 
transmission  of  AK  TPDUs,  the  maximum  amount  of  time  by  which  a 
single  AK  TPDU  may  be  delayed  shall  be  indicated  to  the  peer 
transport  service  provider  using  the  acknowledgement  time 
parameter.  The  value  transmitted  should  be  expressed  in  units 
of  milliseconds  and  rounded  up  to  the  nearest  whole  millisecond. 

o Throughput,  priority,  and  transit  delay  are  optional  in  the  ISO 
specification.  Do  not  send  in  the  CR  TPDU;  ignore  in  the  CC 
TPDU. 

o User  data  in  the  CR  TPDU  and  the  CC  TPDU  are  optional.  No 
implementation  should  send;  all  implementations  must  be  prepared 
to  receive. 

7.1.4  Retr ansmiss ion  Timer 


It  is  recommended  that  the  value  used  for  the  retransmission  timer  be  based 
upon  the  round-trip  delay  experienced  on  a transport  connection.  The 
implementation  should  maintain,  and  continually  update,  an  estimate  of  the 
round-trip  delay  for  the  TC.  From  this  estimate,  a value  for  the 
retransmission  timer  is  calculated  each  time  it  is  started.  An  example 
technique  for  maintaining  the  estimate  and  calculating  the  retransmission 
timer  is  described  below.  Further  information  on  similar  techniques  may  be 
found  in  the  literature  [Edge  84,  Jain  85,  Mill  83]. 
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The  value  of  the  retransmission  timer  may  be  calculated  according  to  the 
following  formula: 


t < kE  + w 

In  this  formula,  E is  the  current  estimate  of  the  round-trip  delay  on  the 
transport  connection,  w is  the  value  of  the  acknowledgement  time  parameter 
received  from  the  remote  transport  service  provider  during  connection 
establishment,  and  k is  some  locally  administered  factor. 

A value  for  k should  be  chosen  to  keep  the  retransmission  timer  sufficiently 
small  such  that  lost  TPDUs  will  be  detected  quickly,  but  not  so  small  that 
false  alarms  are  generated  causing  unnecessary  retransmission. 

The  value  of  E may  be  calculated  using  an  exponentially  weighted  average  based 
upon  regular  sampling  of  the  interval  between  transmitting  a TPDU  and 
receiving  the  corresponding  acknowledgement.  Samples  are  taken  by  recording 
the  time  of  day  when  a TPDU  requiring  acknowledgement  is  transmitted  and 
calculating  the  difference  between  this  and  the  time  of  day  when  the 
corresponding  acknowledgement  is  received.  New  samples  are  incorporated  with 
the  existing  average  according  to  the  following  formula. 

E < aE  + (1  - o )S 

In  this  formula,  S is  the  new  sample  and  alpha  is  a parameter  which  can  be  set 
to  some  value  between  0 and  1.  The  value  chosen  for  alpha  determines  the 
relative  weighting  placed  upon  the  current  estimate  and  the  new  sample.  A 
large  value  of  alpha  weights  the  old  estimate  more  heavily  causing  it  to 
respond  only  slowly  to  variations  in  the  round-trip  delay. 

A small  value  weights  the  new  sample  more  heavily  causing  a quick  response  to 
variations.  (Note  that  setting  alpha  to  1 will  effectively  disable  the 
algorithm  and  result  in  a constant  value  for  E,  being  that  of  the  initial 
seed. ) 

If  alpha  is  set  to  l-2~n  for  some  value  of  n,  the  update  can  be  reduced  to  a 
subtract  and  shift  as  shown  below. 

E < E + 2“n  (S  - E) 

When  sampling,  if  an  AK  TPDU  is  received  which  acknowledges  multiple  DT  TPDUs, 
only  a single  sample  should  be  taken  being  the  round-trip  delay  experienced  bv 
the  most  recently  transmitted  DT  TPDU.  This  attempts  to  minimize  in  the 
sample  any  delay  caused  by  the  remote  transport  service  provider  withholding 
AK  TPDUs. 
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7.1.5  Keep-Alive  Function 


The  Class  4 protocol  detects  a failed  transport  connection  by  use  of  an 
'inactivity  timer'.  This  timer  is  reset  each  time  a TPDU  is  received  on  a 
connection.  If  the  timer  ever  expires,  the  connection  is  terminated. 

The  Class  4 protocol  maintains  an  idle  connection  by  periodically 
transmitting  an  AK  TPDU  upon  expiration  of  the  'window  timer' . Thus,  in  a 
simple  implementation,  the  interval  of  one  transport  entity's  window  timer 
must  be  less  than  that  of  its  peer's  inactivity  timer,  and  vice  versa.  The 
following  agreements  permit  communicating  transport  entities  to  maintain  an 
idle  connection  without  shared  information  about  timer  values. 


o In  accordance  with  ISO  8073,  clause  12. 2. 3. 9. a,  all 
implementations  must  respond  to  the  receipt  of  a duplicate  AK 
TPDU  by  transmitting  an  AK  TPDU  containing  the  ' flow  control 
confirmation'  parameter. 


Implementations  must 
expiration  of  the 
12.2.3.8.1).  Receipt 


__  always  transmit 
local  window  timer 
of  this  TPDU 


duplicate  AK  TPDUs  on 
(see  ISO  8073,  clause 
by  the  remote  transport 
entity  will  cause  it  to  respond  with  an  AK  TPDU  containing  the 
'flow  control  confirmation'  parameter.  When  this  is  received  by 
the  local  transport  entity,  it  will  reset  its  inactivity  timer. 
See  figure  7.1. 


It  is  a local  matter  for  an  implementation  to  set  the  intervals 
of  its  timers  to  appropriate  relative  values.  Specifically: 


o The  window  timer  must  be  greater  than  the  round-trip 
delay.  See  section  7.1.4. 

o The  inactivity  timer  must  be  greater  than  two  times  the 
window  timer;  and  should  normally  be  an  even  greater 
multiple  if  the  transport  connection  is  to  be  resilient 
to  the  loss  of  an  AK  TPDU. 
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A duplicate  AK  TPDU  (See  Figure  7.1.)  is  one  which  contains  the  same  values 
for  YR-TU-NR,  credit,  and  subsequence  number  as  the  previous  AK  TPDU 
transmitted.  A duplicate  AK  TPDU  does  not  acknowledge  any  new  data,  nor  does 
it  change  the  credit  window. 


W 


reset 


reset 


expire 


expire 


expire 


Fig.  7.1  AK  exchange  on  idle  connection 
7.2  TRANSPORT  CLASS  0 


7.2.1  Transport  Class 

Transport  class  0 over  X.25  is  mandatory  (see  X.400)  for  use  in  communicating 
with  public  MHS  systems  operating  in  accordance  with  the  CCITT  X.400  series 
recommendations.  The  purpose  of  the  agreements  concerning  transport  class  0 
is  to  allow  connection  to  these  public  services.  Transport  class  0 over  X.25 
can  also  be  used  in  communicating  between  PRMDs,  but  it  is  agreed  that 
transport  class  4 and  CLNP  over  all  types  of  lower  layer  networks  allows  a 
larger  range  of  interoperation  and  is  recommended. 

7.2.2  Protocol  Interpretation 

Transport  class  0 is  a relatively  simple  protocol  providing  little  opportunity 
for  conflicting  interpretations.  A few  relevant  agreements  follow. 

o The  Disconnect  Request  (DR)  TPDU  shall  be  limited  to  the  first 
seven  octets  - "LI"  plus  "fixed  part". 
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o 


The  Error  (ER)  TPDU  may  be  used  at  any  time  and  upon  receipt 
requires  that  the  recipient  disconnect  the  network  connection, 
and  by  extension  the  transport  connection. 

7.2.3  Rules  for  Negotiation 

The  ISO  rules  for  negotiations  will  be  used. 

7 . 3 CONNECTIONLESS  TRANPORT 

Document  ISO  IS  8072/DAD1  is  the  Transport  Service  Definition  covering 
Connectionless-mode  Transmission.  Document  ISO  DIS  8602  is  the  Protocol  for 
providing  the  Connectionless -mode  Transport  service. 
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8.  SESSION 


Session  services  are  defined  to  meet  the  needs  of  many  applications.  The 
Session  service  is  defined  in  ISO  8326  (CCITT  X.215)  and  the  session  protocol 
is  defined  in  ISO  8327  (CCITT  X.225).  The  general  agreements  about  the  use  of 
session  are  documented  below  in  section  8.1,  followed  by  agreements  that  are 
related  to  specific  applications. 

8 . 1 GENERAL 


The  services  of  the  Session  kernel  functional  unit  are  used  as  specified  in 
the  standard. 


Session  Connection 
Data  Transfer 
Orderly  Release 
Provider  Abort 
User  Abort 

Basic  concatenation  is  required  by  the  session  protocol  standard.  Extended 
concatenation  is  not  required  and  can  be  refused  using  the  normal  negotation 
mechanisms  provided  by  the  session  protocol. 

Session  segmenting  is  not  required  and  can  be  refused  using  the  normal 
negotiation  mechanisms  of  the  session  protocol. 

Reuse  of  a transport  connection  is  not  required  and  can  be  refused  using  the 
normal  negotiation  mechanisms  of  the  session  protocol. 

The  use  of  transport  expedited  is  as  stated  in  the  session  protocol 
specification.  That  is,  if  transport  expedited  is  available  it  must  be  used. 

The  maximum  length  of  the  reflect  parameter  values  parameter  in  the 
3-P-Exception-Report  is  1024  octets. 

The  user  data  parameter  on  S-CONNECT  SPDU  will  allow  unlimited  length  user 
data  as  specified  in  the  proposed  Session  draft  addendum.  This  because  the 
combined  P- CONNECT,  A-ASSOCIATE,  and  F-INITIALIZE  may  exceed  the  existing  512 
byte  limit. 

A mandatory  functional  unit  is  one  that  must  be  implemented  by  the  service 
provider. 

An  optional  functional  unit  is  one  which  the  service  provider  may  implement, 
but  irrespective  of  whether  it  is  implememted  or  not,  must  recognize  and 
respond  to  correct  requests  for  its  use. 

8.2  SESSION  REQUIREMENTS  FOR  FTAM 

The  Phase  2 FTAM  requires  the  following  functional  units  in  addition  to  those 
specified  in  section  8.1. 
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Functional  Units 


Session  Services 


Duplex  ------- 

Note:  Implementation  of  the  Resynchronize  functional  unit  is  highly 
recommended,  since  the  F-CANCEL  service  may  be  ineffective  when  mapped  to 
S-DATA. 


8.3  SESSION  REQUIREMENTS  FOR  MESSAGE  HANDLING 


The  MHS  application  requires  the  following  functional  units  in  addition  to 
those  specified  in  section  8.1. 

Functional  Units  Session  Services 


Exceptions 


User  Exception  Reporting 
Provider  Exception  Reporting 


Activity  Management 


Half -duplex 


Activity  Start 
Activity  Resume 
Activity  End 
Activity  Interrupt 
Activity  Discard 
Please  Tokens 
Give  Tokens 
Give  Control 

Give  Tokens 
Please  Tokens 


Minor  Synchronize  Minor  Synchronization  Point 

Give  Tokens 
Please  Tokens 


Note:  Restricted  use  is  made  by  the  RTS  of  the  session  services 

implied  by  functional  units  selected.  Specifically, 

o No  use  is  made  of  S-TOKEN-GIVE,  and 
o S-PLEASE-TOKENS  only  asks  for  the  data  token. 


The  following  additional  points  should  be  noted. 

o In  S-CONNECT,  the  SynchronizationPointSerial 
Number  should  not  be  present. 

o Format  of  the  SessionConnectionID  is 
described  in  Version  3 of  the  X. 400-Series 
Implementor's  Guide. 
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9.  SERVICE  ACCESS  POINTS  AND  SELECTORS 


The  following  guidelines  on  the  size  of  n-selectors  apply  to  implementations 
based  on  these  agreements  and  therefore  to  incoming  connection  requests  only. 
Outgoing  connection  requests  will  support  the  full  range  of  n-selector  sizes. 

9 . 1 UPPER  LAYER  AGREEMENTS 

The  following  upper  layer  addressing  agreements  have  been  reached. 

o The  combination  of  NSAP  address,  TSAP  selector,  SSAP  selector, 

PSAP  selector  and  PSAP  address  must  be  unique  to  identify  an 
application  entity. 

o It  is  implicitly  agreed  that  the  procedure  followed  for  the 
assignment  of  NSAP  addresses  insures  that  they  are  globally 
unique. 

o The  assignment  of  TSAP,  SSAP,  and  PSAP  selectors  is  a local  end 
system  issue  and  the  values  are  administered  locally. 

o SSAP  selectors  are  encoded  as  a string  of  octets,  the  meaning  of 
which  is  known  only  to  the  local  system.  The  length  of  the 

string  cannot  exceed  16  octets. 

o PSAP  selectors  are  encoded  as  a string  of  octets,  the  meaning  of 
which  is  known  only  to  the  local  system.  The  length  of  the 

string  cannot  exceed  16  octets. 

9.2  TRANSPORT  CLASS  4 SERVICE  ACCESS  POINTS  OR  SELECTORS 

The  TSAP  selector  field  in  the  CR  and  CC  TPDUs  shall  be  encoded  as  a variable 
length  field  and  will  be  interpreted  as  an  octet  string.  The  length  of  the 
string  cannot  exceed  32  octets. 

9.3  TRANSPORT  CLASS  0 SERVICE  ACCESS  POINTS 

For  communi eating  with  public  MHS  systems.  Section  5 of  X.A10  specifies  the 
use  and  format  of  TSAP  identifiers. 
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10.  ISO  FILE  TRANSFER  & ACCESS  MANAGEMENT  PROTOCOL 


10.0  INTRODUCTION 


This  section  defines  Implementors'  Agreements  based  on  the  ISO  File  Transfer, 
Access,  and  Management  (FTAM),  as  defined  in  ISO  DIS  8571.  This  Draft 
International  Standard  has  four  parts.  Part  1 of  the  DIS  gives  general 
concepts.  Part  2 defines  the  Virtual  File  Store  (VFS),  Part  3 defines  the  File 
Service,  and  Part  4 the  File  Protocol. 

FTAM  depends  on  ISO  definitions  of  ASN.l  (ISO  DIS  8824  and  8825),  the 
Presentation  Service  and  Protocol  (ISO  DIS  8822  and  8823),  and  the  Session 
Service  (ISO  8326/CCITT  X.215)  and  Session  Protocol  (ISO  8327/CCITT  X.225), 
and  Transport  Class  4.  FTAM  Phase  2 also  requires  CASE  Services  (ISO  DIS 
8649/2  and  Protocol  (ISO  DIS  8650/2).  These  services  and  protocols  are 
defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498).  This  section 
presumes  that  the  reader  is  familiar  with  these  standards,  and  is  of  a 
technical  level  appropriate  to  implementing  or  testing  them.  This  section 
provides  detailed  guidance  for  the  implementor,  and  is  not  an  FTAM  tutorial. 

The  general  agreements  reached  with  respect  to  the  ISO  File  Transfer,  Access, 
and  Management  Protocol  (FTAM)  are: 

FTAM  will  be  defined  in  at  least  two  phases.  The  Phase  1 FTAM 
implementation  specification  (section  10.1)  is  based  on  the 
second  ISO  draft  proposal,  dated  April  30,  1985^,  and  the  ISO 
draft  proposals  8824  and  8825. 

The  Phase  2 FTAM  specification  (section  10.2)  is  based  on  the 
Draft  International  Standard  (DIS)  and  later  will  be  based  on 
the  International  Standard  (IS).  THERE  IS  NO  BACKWARD 
COMPATIBILITY  WITH  NBS  FTAM  PHASE  1. 

Backward  compatibility  is  impossible,  since  Phase  1 uses  Session  services 
directly,  while  Phase  2 uses  CASE  and  Presentation  services.  Furthermore, 
there  are  differences  in  Filestore,  PDU  Abstract  Syntax,  FADU  Abstract  Syntax, 
and  Transfer  Syntax.  There  also  are  differences  in  the  Transparency 
mechanisms  and  service  class  negotiations. 

Assuming  that  Phase  2 FTAM  implementations  will  be  based  on  the  forthcoming 
IS,  and  that  this  IS  or  the  CASE  IS  provides  the  ability  to  pass  "user 
version"  information,  a mechanism  exists  for  backward  compatibility.  It  is 
the  goal  of  these  agreements  to  use  the  "user  version"  mechanism  to  provide  at 
least  one  level  of  backward  compatibility  for  all  future  NBS  FTAM  Phases, 
facilitating  backward  compatibility  for  future  FTAM  products. 

1 Part  1 is  dated  April  20,  1985;  Part  2 dated  April  29,  1985;  and  Parts  3 
and  4 dated  April  30,  1985. 
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10.1  PHASE  1 FTAM  IMPLEMENTATION  SPECIFICATION 


10.1.1  Phase  1 FTAM  Services 


The  subset  of  file  transfer  services  that  has  been  agreed  to  is: 

F- INITIALIZE 
F- SELECT 
F-OPEN 

F-READ,  F-WRITE 
F-DATA 
F-DATA-END 
F- TRANSFER- END 
F-CLOSE 
F -DESELECT 

F-U- ABORT,  F-P-ABORT 
F~ TERMINATE 

Implementation  of  F-CANCEL  is  optional. 

Both  F-READ  and  F-WRITE  will  be  implemented.  At  most  one  F-OPEN  and  one  F- 
READ  or  F-WRITE  is  permitted  per  file  selection,  but  more  than  one  file  may  be 
selected  sequentially  over  the  lifetime  of  a connection.  A Session 
connection  is  established  at  the  beginning  of  the  file  activity  and  is 
terminated  when  the  file  transfer  connection  is  released  by  an  F-TERMINATE. 

The  limited  management  subset  of  services  that  has  been  agreed  to  is: 

F- CREATE 
F-DELETE 

F-READ- ATTRIBUTE 

Note  that  this  subset  is  complete  with  respect  to  the  ISO  limited  file 
management  functional  unit. 

The  <user  correctable  file  service>  and  the  <storageAttributeGroup>  subset  of 
the  virtual  filestore  attribute  group  are  to  be  implemented. 

10.1.2  Phase  1 Attributes 


The  following  attributes  have  been  agreed  upon. 
10.1.2.1.  File  Attributes 


Phase  1 FTAM  implementations  will  negotiate  the  use  of  Storage  file 
attributes.  A value  for  the  following  attributes  must  be  maintained. 

1.  FILENAME 

The  minimum  range  of  <filename>  values  specified  in  DP8571  Part  2 Section  11 
is  supported  (1-8  characters),  with  no  maximum  length  or  format  restriction. 
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Any  system  that  does  not  support  extended  <filename>  characteristics  would 
reject  the  F-SELECT  or  F-CREATE  request  of  such  a <filename>.  Values  of 
<filename>  are  to  consist  of  upper-case  letters  (A-Z)  and  numbers  <0-9>,  and 
must  begin  with  a letter. 

2.  ACCESS  STRUCTURE  TYPE 

The  value  of  <accessStructureType>  type  is  <unstructured> . The 

<accessStructureType>  attribute  values  <flat>  and  <hierarchical>  are  not  used. 

3.  PRESENTATION  CONTEXT  NAME  J 

Two  structures  for  <presentationContextName>  have  been  approved. 

VARCRLF : Text  format.  Each  line  is  variable  length  and  must  be 

terminated  by  a CRLF  pair.  Maximal  line  length  is  250  characters  plus 
CRLF.  Form  feed  is  excluded.  CR  and  LF  cannot  occur  separately.  The 
ISO  646  character  set  is  to  be  used. 

UNDEF:  Octetstring  encoding.  No  embedded  structure  is  recognized. 

4.  CURRENT  FILESIZE 

The  current  filesize  value  conforms  with  the  second  ISO  draft  proposal. 

5 . REQUESTED  ACCESS 

The  <Requested  access>  parameter  may  have  <read>,  <replace>,  <read  attributed 
and  <delete  file>  attribute  values. 

In  addition  to  the  above  attributes,  implementations  are  encouraged  to 
maintain  the  following  values. 

1.  FUTURE  FILESIZE 

The  <futureFilesize>  parameter  is  a provider  option,  conforming  to  the  second 
ISO  draft  proposal. 

2.  DATE  AND  TIME  OF  CREATION 

The  <dateAndTimeOfCreation>  parameter  is  a provider  option.  The  value 
conforms  with  the  second  ISO  draft  proposal;  its  resolution  and  accuracy  are 
implementation  dependent. 

10.1.2.2  Activity  Attributes 

Phase  1 FTAM  implementations  negotiates  the  use  of  Storage  activity 
attributes.  Other  attributes  defined  are: 

1.  CURRENT  ACCESS  STRUCTURE  TYPE 

The  <current  access  structure  type>  has  the  <unstructured>  attribute  value. 
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2.  CURRENT  PRESENTATION  CONTEXT 


The  <current  presentation  context>  is  the  same  as  PRESENTATION  CONTEXT,  i.e., 
VARCRLF  or  UNDEF. 

10.1.3  ISO  Deviations  and  Selections 

1.  F-CANCEL  (DP8571/3  8.1  Table  1) 

Implementation  of  the  F-CANCEL  service  for  irrecoverable  errors  in  the  Read 
Functional  Unit  and  Write  Functional  Unit  is  optional.  An  implementation  that 
receives  an  F-CANCEL  indication  may  issue  an  F-P- ABORT  or  F-U-ABORT. 

2.  Grouping  Functional  Unit  (DP8571/3  8.2  lb) 

There  is  no  implementaiton  of  the  Grouping  Functional  Unit.  The  concatenation 
constraint  on  establishing  and  releasing  a <f ileOpenRegime>  is  not  supported. 

3.  F- INITIALIZE  (DP8571/3  14.1.2) 

Values  have  been  chosen  for  these  F-INITIALIZE  parameters: 

Parameter  Value 


serviceType 
(DP8571/3  ,14.1.2.5) 

serviceClass 
(DP8571/3  14.1.2.6) 

functionalUnits 
(DP8571/3  14.1.2.7) 

attributeGroups 
(DP8571/3  14.1.2.8) 

rollbackAvailability 
(DP8571/3  14.1.2.9) 

presentationContextName 
(DP8571/3  13.1.2.11) 


userCorrectable 

file  transfer  class 

{read, write, 

1 imi t edF i leManagemen t } 

storage 

no  rollback 

defined  in  section 
10.1.2  of  this  document 


The  Abstract  Syntax  for  F-INITIALIZE  is: 

F-INITIALIZErequest  ::=  SEQUENCE { 

protocolld  [0]  INTEGER  {isoFTAM  (0)}, 
versionNumber  [1]  IMPLICIT  SEQUENCE{ 
major  INTEGER,  minor  INTEGER}, 
--initially  {major  0,  minor  0}-- 
serviceType  [2]  INTEGER { 
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reliable  (0),  userCorrectable  (1)} 
serviceClass  [3]  INTEGER  {transfer  (0), 
access  (1),  management  (2)}, 
functionalUnits  [4]  BITSTRING{ 

read  (0),  write  (1),  fileAccess  (2), 
limitedFileManagement  ( 3 ) , 
enhancedF i leManagement  ( 4 ) , 
grouping  (5),  recovery  (6), 
restartDataTransfer  (7)}, 
attributeGroups  [5]  BITSTRING{ 
storage  (0),  security  (1)}, 
rollbackAvailability  [6]  BOOLEAN  DEFAULT  FALSE, 
presentationContextNames  [10]  IMPLICIT 

SEQUENCE  OF  PresentationContextName  OPTIONAL, 
identityOf Initiator  [7]  Graphicstring  OPTIONAL, 

CurrentAccount  OPTIONAL, 

f ilestorePassword  [8]  OCTETSTRING  OPTIONAL, 
checkpointWindow  [9]  INTEGER  OPTIONAL) 

F-INITIALIZEresponse  : :=  SEQUENCE { 

Diagnostic, 

protocolID  [0]  INTEGER  {isoFTAM  (0)}, 
versionNumber  [1]  IMPLICIT  SEQUENCE{ 
major  INTEGER,  minor  INTEGER), 

— initially  {major  0,  minor  0)-- 
serviceType  [2]  INTEGER{ 

reliable  (0),  userCorrectable  (1)), 
serviceClass  [3]  INTEGER  {transfer  (0), 
access  (1),  management  (2)), 
functionalUnits  [4]  BITSTRING{ 

read  (0),  write  (1),  fileAccess  (2), 
limitedFileManagement  (3), 
enhancedF i leManagement  ( 4 ) , 
grouping  (5),  recovery  (6), 
restartDataTransfer  (7)), 
attributeGroups  [5]  BITSTRING{ 
storage  (0),  security  (1)), 
rollbackAvailability  [6]  BOOLEAN  DEFAULT  FALSE, 
presentationContextNames  [8]  IMPLICIT 

SEQUENCE  OF  PresentationContextName  OPTIONAL, 
checkpointWindow  [7]  INTEGER  OPTIONAL) 

If  the  <PresentationContextName>  parameter  is  present,  its  value  will 
establish  the  limits  of  the  life  of  the  FTAM  association. 

4.  F-OPEN 

The  values  of  the  <ProcessingMode>  parameters  chosen  are  <read>  or  <replace> 
(DP8571/3  17.1.2.2). 

With  FmOPEN,  the  <presentationContext>  parameter  must  be  present  to  indicate 
the  context  chosen  for  the  transfer,  since  there  is  currently  no  Presentation 
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Layer  implementation  (DP8571/3  17.1.2.3). 

5 . F-DATA 

(DP8571/3  24.3.)  F-DATA  is  encoded  as: 

IDENTIFIER:  context  specific  tag  value  [55] 

Length:  (Length  of  OCTETS) 

Contents:  (octets) 

There  is  an  explicit  F-DATA  PDU  because  of  the  direct  FTAM/ Session  mapping. 
The  ASN.l  definition  of  F-DATA  is: 

F-DATArequest  ::=  [55]  IMPLICIT  OCTETSTRING 

6.  IS0646String  ASN.l  TYPE 

The  ASN.l  type  <IS0646String>  is  used  instead  of  ASN.l  type  <GraphicString>  in 
the  abstract  syntax.  Wherever  <GraphicString>  is  specified  in  the  abstract 
syntax,  the  abstract  syntax  is  modified  by  <IS0646String> . 

7.  Presentation  Context 

The  <PresentationContext>  attribute  on  the  SELECT/CREATE  request  is  restricted 
to  only  one  <presentationContextName> . 

<presentationContextName>  parameters  are  encoded  as: 
PresentationContextName  ::=  [Application  13] 

PrintableString 

On  F-OPEN  Requests  and  Responses,  the  <presentationContextName>  parameter  is 
mandatory,  not  optional. 

8.  State  Machine 

Phase  1 FTAM  products  will  use  the  state  machine  in  the  second  ISO  draft  FTAM 
proposal,  part  4,  except  where  explicitly  specified  differently  in  these 
agreements . 

10.1.4  Further  Implementation  Details 

The  following  recommendations  are  not  specified  by  the  standard  but  have  been 
agreed  upon  in  order  to  ensure  that  different  implementations  work  together 
smoothly. 

1.  FTAM  Phase  1 Use  of  Session  Service 

This  FTAM  implementation  is  mapped  directly  to  Session  services  and  does  not 
use  CASE.  The  F-INITIALIZE  Request  is  embedded  in  the  S-CONNECT  Request  and 
the  F-INITIALIZE  Response  is  embedded  in  the  S-CONNECT  Response,  instead  of 
being  sent  as  S-DATA  request  after  the  Session  has  been  established. 
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If  the  F-INITIALIZE  Response  is  a positive  confirmation,  that  Response  is 
mapped  onto  ACCEPT  SPDU.  Otherwise,  it  is  mapped  onto  REFUSE  SPDU. 

F-U-ABORT  and  F-P-ABORT  are  mapped  to  S-DATA  Requests.  The  receiver  of  an 
F-U-ABORT  or  an  F-P-ABORT  must  issue  an  S-U-ABORT  Request.  This  avoids 
S-RELEASE  collison  should  both  entries  wish  to  abort  simultaneously. 

2.  Parameter  Parsing  and  Support 

Implementations  should  be  able  to  parse  all  valid  second  ISO  draft  proposal 
optional  parameters  if  they  are  present  in  the  PDU.  Only  those  optional 
parameters  specified  in  the  agreements  are  required  to  be  supported  for 
request  and  response  PDUs. 

All  second  ISO  draft  proposal  optional  parameters  identified  in  these 
agreements  as  mandatory  must  be  supported.  If  this  parameter  is  not  present, 
its  semantics  are  a local  issue.  Furthermore,  the  request  should  not  be 
refused. 

3.  Error  Handling  and  Diagnostics 

Error  handling  and  diagnostic  action  that  is  permitted  by  the  standard  is  not 
restricted.  Implementations  may  return  a response  with  a negative  diagnostic 
or  issue  an  F-U-ABORT  request. 

In  the  FTAM  second  ISO  draft  proposal,  the  parameter  <diagnostic>  is  defined 
as  <ImplicitSequenceOfDiagnostics>.  The  order  of  the  diagnostics  in  the 
sequence  is  arbitrary  and  has  no  significance. 

4.  Rollback 

Specifying  <No  rollback>  implies  that,  in  case  of  failure,  the  status  of  the 
involved  files  is  unpredictable.  Implementors  of  receivers  may  choose  to 
leave  the  partially  transferred  file  as  is,  or  they  may  cancel  it. 

However,  in  order  to  avoid  dangling  conditions,  after  a failure  (i.e.,  after 
an  F-U-ABORT  or  F-P-ABORT)  it  is  recommended  that  files  always  be  put  in  a 
status  that  does  not  prevent  further  access  both  from  remote  and  local 
systems . 

5 . Concurrency 

No  concurrency  rules  have  been  adopted,  since  the  file  attributes  governing 
them  will  not  be  supported.  Therefore,  each  implementation  may  choose  the 
degree  of  concurrency  of  the  local  files  as  a local  matter.  However,  in  order 
to  minimize  possible  errors,  the  following  implementation  rules  are 
recommended. 

a.  A file  may  be  involved  in  several  transfers  simultaneously  only 
if  accessed  in  reading  mode. 
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b.  If  a file  is  involved  in  a transfer  in  writing  mode,  any  other 
request  for  access  to  that  file  (either  for  Read  or  Write) 
should  be  rejected. 

c.  A file  cannot  be  modified  by  local  users  while  it  is  involved  in 
a transfer  operation,  either  in  F-READ  or  F- WRITE.  (As  a 
practical  matter,  this  may  be  very  difficult  to  implement, 
regardless  of  the  protection  mechanisms  provided  by  the  local 
operating  system. ) 


6.  ASN.l 

ISO  ASN.l  syntax  is  used  for  encoding  PDU  headers.  ASN.l  encoding  using  the 
indefinite  length  style  is  not  supported. 

7.  Maximum  PDU  Length 

The  maximum  PDU  length  is  1024  octets. 

8.  Response  to  F-READ -ATTRIBUTE 

If  an  F-READ- ATTRIBUTE  request  specifies  an  NBS  optional  attribute  that  is  not 
supported  by  an  implementation's  virtual  filestore,  then  that  attribute  will 
not  be  returned  in  the  <read  attribute>  response.  It  is  recommended  that  an 
implementation  return  an  appropriate  diagnostic  in  this  situation  (e.g.,  4000, 
"attribute  non-existent"). 

9.  Corrupted  S-CONNECT  Indication  User  Data 

If  a Responder  receives  an  S-CONNECT  indication,  and  the  user  data  carried  on 
that  indication  are  "corrupted"  (i.e.,  decoding  the  PCI  results  in  an 
irrecoverable  error),  then 

a.  If  the  user  data  can  be  identified  as  an  F-INITIALIZE  request, 
the  Responder  should  respond  with  an  F-INITIALIZE  response  (-) 
or  F-P-ABORT  with  diagnostic  conveying  an  irrecoverable  error. 

This  is  to  be  carried  on  an  S-CONNECT  response  (-),  i.e., 
rejecting  the  connection. 

The  Responder  should  further  clarify  the  error  in  the  < further 
details>  field  of  the  <Diagnostic>  PDU. 

Parameters  on  the  F-INITIALIZE  response  should  be  reflected 
where  appropriate;  where  this  is  not  possible,  default  values 
should  be  chosen  by  the  Responder  where  mandatory  parameters  are 
required  and  cannot  be  reflected. 
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b.  If  the  user  data  cannot  be  identified  as  an  F-INITIALIZE 
request,  the  Responder  should  respond  with  an  S-U-ABORT  and  a 
reason  code  appropriate  to  the  error. 
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10,2  PHASE  2 FTAM  IMPLEMENTATION  SPECIFICATION 


10.2.1  Assumptions 

1.  These  agreements  are  based  on  the  ISO  8571  DIS  version  of  FTAM.  When  the 
IS  text  is  approved  following  the  close  of  DIS  ballots,  the  agreements  will  be 
modified  as  necessary  to  meet  the  IS  specifications. 

2.  FTAM  protocol  machines  must  be  able  to  parse  and  process  up  to  7K  octets 
of  File  PCI  and  FTAM  user  data  (including  grouped  FPDUs)  as  they  would  be 
encoded  with  the  ASN.l  Basic  Encoding  Rules.  It  is  recommended,  however,  that 
Presentation  user  data  not  be  restricted  in  size. 

3.  In  order  to  maximize  interoperability,  it  is  important  that  the 
implementations  of  FTAM  service  providers  do  not  unnecessarily  restrict  the 
service  user's  ability  to  generate  arbitrary  file  service  requests. 
Otherwise,  they  may  not  be  able  to  work  with  FTAM  Responders  whose  operation 
is  constrained  by  their  mapping  of  the  FTAM  virtual  filestore  to  their  local 
filestore.  For  example,  error  procedures  should  only  be  invoked  when  an  error 
actually  occurs,  not  at  the  point  of  the  specification  of  options  which  might 
result  in  a error. 

4.  Implementations  must  be  able  to  parse  all  valid  DIS  optional  parameters  if 
they  are  present  in  the  PDU.  Only  those  optional  parameters  specified  as 
mandatory  in  these  agreements  are  required  to  be  supported  for  Request  and 
Response  PDUs.  If  these  parameters  are  not  present,  a default  value  is 
assigned  locally.  A responder  should  not  refuse  a request  solely  because  a 
parameter  that  is  optional  in  the  FTAM  standard,  but  is  mandatory  in  these 
agreements,  is  not  present. 

5.  Consideration  of  any  standarized  service  interface  is  not  covered  by  these 
agreements . 

10.2.2  Presentation  Agreements 

The  following  Abstract  Syntaxes  are  supported. 

ISO  8571 -FTAM  (including  ISO  8571-FADU) 

ISO  8650-ACSE1 
NBS-AS1 
NBS-AS2 
NBS-AS3 

If  the  presentation  context  management  functional  unit  is  available,  it  is 
possible  to  use  P- ALTER -CONTEXT  to  negotiate  the  use  of  an  abstract  syntax. 

See  section  11.2  for  definition  of  the  <object  Identified  for  <ISO  8571-FTAM> 
and  <IS0  8650-ACSEl>. 
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10.2.3  FTAM  Service  Type  Agreements 

The  Reliable  File  Service  level  (excluding  Recovery  and  RestartDataTransfer 
functional  units)  is  to  be  implemented.  Implementing  the  error  recovery 
protocol  machine  is  not  required. 

10.2.4  Service  Class  Agreements 

Implementation  of  the  following  service  classes  is  defined. 

o File  Transfer 
o File  Access 
o File  Management 
o File  Transfer  and  Management 
o Unconstrained 

10.2.5  Functional  Unit  Agreements 

Implementation  of  the  following  functional  units  is  defined. 

o Kernel 
o Read 
o Write 
o File  Access 
o Limited  File  Management 
o Enhanced  File  Management 
o Grouping 

10.2.6  File  Attribute  Agreements 

Implementation  of  the  Kernel  Group  of  file  attributes  is  defined.  If  the 
optional  Storage  Group  and  Security  Group  are  implemented,  aspects  of  their 
implementation  are  defined.  Implementation  of  the  Private  Group  is  not 
specified. 

Responses  to  an  attribute  value  request  shall  always  include  one  of  the 
following: 

1.  An  actual  file  attribute  value. 

2.  A value  indicating  that  the  attribute  value  is  not  available  at  this  time. 
Optionally,  a diagnostic  may  be  provided  indicating  that  the  attribute  is  not 
supported. 

The  <Contents  Type>  attribute  is  limited  to  the  <DocumentTypeName>  form. 
Mandatory  Group 

A value  for  file  name  and  contents  type  will  always  be  available.  Only  the 
Kernel  Group  of  attributes  is  required. 
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A minimum  range  is  required  for  <filename>  values  (1-8  characters).  No 
maximum  length  or  format  restrictions  apply.  A system  that  does  not  support 
multi -component  <f ilename>  values  or  extended  <filename>  characteristics  may 
reject  a request  involving  such  a <filename>.  All  systems  must  be  able  to 
interpret  a <filename>  with  single  component  values.  Requests  using  single 
component  <filename>  values  are  responded  to  using  single  component  <filename> 
values.  Responses  to  requests  involving  <filename>  values  having  two  or  more 
components  are  not  defined  here  but  may  be  interpreted  via  bilateral  or  other 
external  agreements.  Use  of  <filename>  values  with  multiple  components  is 
discouraged. 

Optional  Groups 

If  the  optional  Storage  Group  of  file  attributes  is  implemented,  an  actual 
value  must  be  available  for  the  <PermittedActions>  attribute. 

If  the  optional  Security  Group  of  file  attributes  is  implemented,  an  actual 
value  must  be  available  for  the  <AccessControl>  attribute. 


Implementation  of  the  <Private>  Group  is  not  specified. 
10.2.7  Document  Type  Agreements 
These  document  types  are  defined. 


NBS-1  UNDEF 
NBS-2  VARCRLF 
NBS-3  S859VARCRLF 
NBS-4  TEXT 
NBS-5  8859TEXT 
NBS-6  SEQUENTIAL 
NBS-7  RANDOM 
NBS-8  INDEXED 
NBS-9  FILE  DIRECTORY 


Part  of  our  ongoing  work  is  to  define,  discuss,  and  propose  other  file  types. 
Detailed  document  type  definitions  are  given  in  Appendix  D. 


Document  type  Names: 

DTN  : : = DTName  | DTName  params 
DTName  : :=  OBJECT  IDENTIFIER 
params  : : = param  | :param  params 
param  : :=  PrimType  | PrimType,  param 

PrimType  :=  INT  - <n*> 

BIT  - <n2> 

IA5  - <nl> 

8859  - <nl> 

OCT  - <nl> 

UTC 

GEN 
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NULL 

BOOL 

FLOAT  - <n3,  n4> 

<nl>  - Maximum  number  of  characters/octets  in  string. 

<n2>  - Number  of  bits  in  string  (i.e.,  nonvarying). 

<n3>  - The  minimum  number  of  bits  required  to  be  maintained  in  the  mantissa 
for  relative  precision. 

<n4>  - Number  of  bits  required  to  represent  the  largest  unbiased  integer  in 
2 1 s complement . 

<n*>  - Number  of  octets  required  to  represent,  in  2's  complement  format,  the 
largest  integer  to  be  passed. 

The  primitive  data  types  and  minimal  size  range  that  an  implementation  must 
accept  are  given  in  the  table  10.1. 


Tbl. 

10.1  FTAM  primitive  data 

types 

PRIMITIVE  DATA  TYPE 

REPRESENTATION 

MINIMUM  RANGE  (OCTETS) 

IN  PARAMETER 

ASN.l 

INTEGER 

INT  <N*> 

(1 

- 2) 

ASN.l 

Bit  String 

BIT  <N2> 

(0 

- 1) 

ASN.l 

IA5String 

IA5  <N1> 

(0 

- 134) 

NBS-AS1 

8859String 

8859  <N1> 

(0 

- 134) 

ASN.l 

OCTETSTRING 

OCT  <N1> 

(0 

- 512) 

ASN.l 

BOOLEAN 

BOOL 

ASN.l 

NULL 

NULL 

ASN.l 

Generalized  Time 

GEN 

ASN.l 

Universal  Time 

UTC 

NBS-AS1 

Floating  Point 

FLOAT  <N3 ,N4> 

Note:  The  primitive  data  types  and  their  maximum  ranges  for  a specific  file 

as  described  by  the  parameters  above  are  maintained  in  the  contents 
type  file  attribute.  The  contents  type  file  attribute  value  is 
established  at  the  file's  creation  and  cannot  be  changed  via  FTAM  for 
the  life  of  the  file.  This  implies  that  the  data  element  types  and 
ranges  and  data  unit  formats  are  fixed  for  all  accessors  of  that  file 
as  long  as  the  file  exists. 

An  <object  identified  is  a string  of  integers;  FTAM  <document  type> 
parameterization  is  achieved  by  exploiting  that  structure. 

The  final  registration  authority  entity  is  followed  by  a <data  unit> 
description.  The  <data  unit>  description  is  a series  of  data  element 

descriptions.  Each  <data  element>  description  is  an  integer  identical  to  the 
ASN.l  type  code,  followed  by  any  required  parameter  values,  as  integers. 
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The  following  values  correspond  to  the  NBS  primitives  not  found  in  ASN.l  and 
the  integer  value  for  (separator). 

FLOAT  - 127 
8859  - 126 
: - 125 

Following  is  an  example  of  how  an  indexed  file  with  three  fields  (2-byte 
integer,  4-byte  integer  and  10-character  IA5String),  with  the  key  being  the 
second  field,  would  be  encoded: 

DTN:  INT(2) , INT(4),  IA5(10):  INT(4) 

This  is  derived  from  the  grammar  for  document  type  names  give  above.  It  would 
be  represented  in  the  encoding  of  the  Object  Identifier  as: 

(encoding  for  base  document  type  name)  125  22  2 4 22  10  125  2 4 

This  is  derived  by  applying  the  encoding  rules  given  above. 

The  following  notation  allows  the  transfer  of  floating  point  numbers,  while 
retaining  their  meaning,  as  defined  by  existing  standards  IEC  559  and  IEEE 
754. 


FloatingPointNumber  : := 

[PRIVATE  0]  CHOICE! 

finite  [0] 

Sign, 

IMPLICIT  SEQUENCE! 

mantissa 

BIT  STRING, 

exponent 

INTEGER} , 

infinity 

[1]  IMPLICIT  Sign, 

signallingNaN 

[2]  IMPLICIT  NaN, 

quiteNaN 

[3]  IMPLICIT  NaN, 

zero 

[4]  IMPLICIT  NULL} 

Sign 

::=  INTEGER! 

positive 

(0), 

negative 

(1)} 

NaN 

::=  INTEGER 

Notes:  1.  The  mantissa  is  a number  in  the  range  (1/2  < mantissa  <1). 

2.  The  value  is  equal  to  mantissa  * 2 exPonent. 

3.  The  first  bit  in  the  mantissa  is  most  significant. 

4.  See  IEEE  754  for  definitions  of  terminology,  such  as  NaN. 

10.2.7.1  Character  Sets 


IA5  and  8859/1  character  sets  have  been  specified,  and  are  to  be  implemented 
as  described  below. 

1.  IAS 
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The  IA5  character  set  leaves  2 options  and  10  characters  unspecified.  The 
definitions  used  are: 

2/3  # 

2/4  $ 

4/0  @ 

5/11  [ 

5/12  \ 

5/13  ] 

5/14 

6/0  ' 

7/11  { 

7/12  | 

7/13  } 

7/14 

Note:  This  is  exactly  the  International  Reference  Version  (IRV)  specified  in 
the  IA5  standard  except  that  the  code  2/4  has  the  graphic  rendition  "$" 
instead  of  the  IRV-specif ied  value  of  the  International  Currency  Symbol. 

Control  characters  should  be  handled  as  follows. 

a.  Semantics  of  format  effectors  will  be  preserved. 

b.  Transmission  control  characters,  device  control  characters, 
information  separators,  and  "other"  control  characters  is  simply 
preserved  via  their  codes. 

c.  Code  extension  shall  not  be  used.  If  it  is-  received,  the  code 
extension  characters  should  be  preserved,  as  in  the  case  of  the 
transmission  control  characters,  and  any  printing  characters 
that  form  later  parts  of  escape  sequences  is  interpreted  as 
stand  alone  characters. 

d.  Combined  horizontal  and  vertical  movement  of  cursor  positioning 
is  not  be  preserved. 

2.  8859/1 

The  Latin  Alphabet  No.  1 is  used  to  specify  the  printable  rendition  of  CO  and 
Cl.  CO  control  characters  and  their  associated  rules  are  taken  from  the  IAS 
definition.  Cl  control  characters  simply  have  their  codes  preserved  across  a 
transfer. 

10.2.7.2  Document  Type  Negotiation  Rules 
1 . Connection  Establishment 

In  Connection  Establishment,  <DocumentTypeName>  values  are  negotiated  by 
subset  of  the  proposed  base  set  of  <DocumentTypeName>  values,  without  regard 
to  DU  syntax  parameter(s)  that  may  be  supplied  on  any  <DocumentTypeName>  that 
requires  a DU  syntax  specification. 
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2.  File  Creation 


An  F-CREATE  Request  FPDU  must  contain  a <DocumentTypeName>  value  from  the 
negotiated  set  of  base  <DocumentTypeName>  values.  If  the  <DocumentTypeName> 
used  requires  DU  syntax  parameters,  then  these  parameters  must  be  supplied. 
If  the  <DocumentTypeName>  used  requires  DU  syntax  parameters  and  none  are 
provided  on  the  F-CREATE  Request,  then  the  F-CREATE  Request  FPDU  must  be 
rejected. 

3.  File  Opening 

It  is  recommended  that  the  F-OPEN  Request  use  the  <DocumentTypeName>  form 
(with  appropriate  DU  syntax  parameters)  when  proposing  a <Contents  Type>,  in 
preference  to  the  <Constraint  Set  Name>  and  <Abstract  Syntax  Name>  form. 

Similarly,  an  F-OPEN  response  should  use  the  <DocumentTypeName>  option  (with 
appropriate  DU  syntax  parameters)  in  the  <Contents  Type>  field.  This  allows 
the  receiving  entity  to  use  the  <DocumentTypeName>  attributed  to  the  file 
instead  of  receiving  a Constraint  Set  Name>  and  <Abstract  Syntax  Name>  pair, 
which  does  not  reflect  the  file  information  contained  in  the  NBS  document 
types . 

Note:  An  F-OPEN  response  without  a <DocumentTypeName>  (but  carrying  the 

Constraint  Set  Name>  and  <Abstract  Syntax  Name>  form)  may  cause  the  initiator 
to  issue  an  F- CLOSE  request. 

10.2.7.3  Relationship  Between  DUs,  DEs  and  Document  Types 

"Abstract  Syntax"  is  used  to  refer  to  the  syntactic  information  which  is 
architecturally  passed  between  the  Application  and  Presentation  Layers.  The 
Abstract  Syntax  defines  Data  Element  (DE)  types  which  are  not  necessarily 
ASN.l  primitive  types.  A Data  Element  (DE)  is  the  smallest  piece  of  data 
whose  identity  is  necessarily  preserved  by  the  Presentation  Service.  Data 
types  may  be  made  up  of  other  data  types.  Data  Elements  are  not  defined  in 
terms  of  other  Data  Elements. 

A <data  unit>  (DU)  is  a sequence  of  one  or  more  data  elements. 
Architecturally,  entire,  single  DEs  are  passed  into  and  out  of  the  application 
process.  In  a real  implementation,  DUs  may  be  passed. 

To  maintain  DU  boundaries  during  transfer,  file  structuring  information  must 
be  passed  (ISO  8571-FADU  DEFINITIONS,  FTAM  Part  2 section  5.3.2).  A data 
element  is  referred  to  as  a File  Contents  Data  Element  in  ISO  8571-FADU 
DEFINITIONS . 

Document  types  refer  to  aspects  of  local  processing  and  storage.  They 
describe: 

o structural  relationship  between  DUs, 
o structure  of  DUs,  called  DU  syntax,  and 
o data  element  types  found  in  the  file. 
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Because  document  types  pertain  to  local  processing  and  storage,  the  DU  syntax 
makes  assertions  about  the  syntax  and  the  size  of  DUs  (records)  in  storage. 
Parameters  on  the  document  types  provide  this  information  about  the  syntax  and 
size  of  the  DUs. 

10.2. 8 F- CANCEL  ACTION 


When  an  F-CANCEL  is  sent  or  received,  the  following  occurs: 

o no  more  data  is  sent, 
o <checkPointNumbers>  are  removed,  and 
o state  of  the  file  is  implementation  dependent. 

10.2.9  Diagnostic  Agreements 

1 . A <diagnostic>  parameter  is  mandatory  only  when  the  Action 
Result  or  State  Result  is  not  zero.  (The  nature  of  these 
agreements  is  to  provide  <diagnostic>  information  when  any 
result  parameter  is  not  <success>.) 

2.  General  catch-all  diagnostic  action  is  discouraged. 

3.  A <furtherDetails>  subfield  is  mandatory.  Use  of  octet  string 
is  discouraged. 

4.  Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic 
situations  is  discouraged. 


55 


5 . 


When  returning  an  error  status  in  a file  management  related 
diagnostic  (i „ e . , F-READ-ATTRIBUTEresponse  or  F- 
CHANGE-ATTRXBUTEresponse) » identify  the  erroneous  attribute  by 
using  the  first  two  characters  of  <further-details>  to  hold  a 
2-digit  number  (encoded  in  IA5String)  from  the 
F-READ-ATTRIBUTErequest  attributes  abstract  syntax  definition 
(ISO/DIS  8571/4  section  20-4): 


00 

Filename 

01 

Contents -Type 

02 

Storage  Account 

03 

Date  and  Time  of  Creation 

04 

Date  and  Time  of  Last 
Modification 

05 

Date  and  Time  of  Last  Read 
Access 

06 

Date  and  Time  of  Last 
Attribute  Modification 

07 

Identity  of  Creator 

08 

Identity  of  Last  Modifier 

09 

Identity  of  Last  Reader 

10 

Identity  of  Last  Attribute 
Modifier 

11 

File  Availability 

12 

Permitted  Actions 

13 

Filesize 

14 

Future  Filesize 

15 

Access  Control 

16 

Encryption  Name 

17 

Legal  Qualifications 

18 

Private  Use 

6.  The  set  of  File  Management  <diagnostics>,  found  in  Table  44  of 
ISO  8571/3  Annex  A,  must  be  maintained. 

7.  The  <diagnostic>  parameter  values  defined  in  FTAM  (8571/3  Annex 
A)  are  partitioned  into  sets  that  apply  to: 

a.  general  FTAM  <diagnostics>  (all  but  identification  * 1 
are  recommended  against), 

b.  Protocol  and  supporting  services, 

c.  the  <FTAM  Regime>, 

d.  the  <File  Selection  Regime>, 

e.  the  <File  Open  Regime>, 

f.  the  <Data  Transfer  Regime>. 

Each  of  those  sets  is  further  partitioned  into  <diagnostics>  applicable  to 
each  parameter  of  the  corresponding  service  elements. 

In  the  case  where  a specific  parameter  can  in  no  way  be  accomodated  then  the 
request  fails  and  a <diagnostic>  indicating  one  such  parameter  should  bm 
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returned  by  the  responder.  In  the  case  where  a negotiable  parameter  cannot  be 
accomodated  with  exactly  the  value  requested  but  is  negotiated  to  a different 
value  (as  defined  in  section  10.2.13)  then  the  request  formally  succeeds  but 
informative  <diagnostics>  indicating  those  parameters  negotiated  should  be 
returned. 

10.2.10  Concurrency 


The  Concurrency  control>  used  by  default  on  the  file  selection  and  file  open 
regime  for  the  first  file  accessor  of  a file  is: 


read 

shared 

insert 

exclusive 

replace 

exclusive 

extend 

exclusive 

erase 

exclusive 

rattr 

shared 

cattr 

exclusive 

del  file 

exclus ive 

For  subsequent  file  accessors,  the  <requestedAccess>  and  <processingMode> 
service  parameters  are  checked  against  this,  and  access  given  only  if  the 
request  is  for  operations  that  are  shared. 

10.2.11  Requested  Access 

The  <RequestedAccess>  parameter  on  <F-SELECT>  or  <F-CREATE>  is  used  to  specify 
the  actions  which  the  initiator  may  perform  during  the  file  selection.  The 
value  of  the  <RequestedAccess>  parameter  is  compared  by  the  responder  to  the 
<AccessControl>  and  <PermittedActions>  file  attributes  and  concurrency 
controls  (including  those  requested  by  the  initiator)  currently  in  place  on 
the  file.  If  the  value  of  the  <RequestedAccess>  parameter  is  not  consistent 
with  either  <AccessControl> , <PermittedActions> , or  concurrency  controls  in 
place,  then  the  <F-SELECT>  or  <F-CREATE>  must  be  rejected. 

<RequestedAccess>  is  consistent  with  <AccessControl>  if,  for  each  action 
requested,  that  action  either  requires  no  password,  or  the  required  password 
has  been  specified  on  the  <F-SELECT>  or  <F-CREATE>  request. 

<RequestedAccess>  is  consistent  with  <PermittedActions>  i,f  for  each  action 
requested,  that  action  is  allowed  by  the  <PermittedActions>  file  attribute. 

<RequestedAccess>  is  consistent  with  <ConcurrencyControl>  requested  on  the  <F- 
SELECT>  or  <F-CREATE>  if,  for  each  action  requested,  that  action  has  not  been 
specified  as  <not  required>  or  <not  allowed>  in  the  <ConcurrencyControl> 
parameter . 

<RequestedAccess>  is  consistent  with  concurrency  controls  in  place  on  the  file 
if  for  each  action  requested  no  other  accessor  of  the  file  has  set  the 
concurrency  control  for  that  action  to  either  <exclusive>  or  <not  allowed>. 

10.2.12  Security 
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10.2.12.1  Optional  Password  Support 


Users  may  provide  values  for  <InitiatorIdentity>  and  <FilestorePassword> . 
Password  support  in  FTAM  is  not  required.  If  this  information  is  provided,  it 
will  be  sent  to  the  Responder  on  the  F-INITIALIZE. 

The  syntax  of  <InitiatorIdentity>  and  <FilestorePassword>  is  system- 
dependent.  <XnitiatorIdentity>  and  <FilestorePassword>  will  represent 
'account'  information  on  the  local  system,  which  may  be  different  from  the 
<account>  parameter. 

10.2.12.2  Access  Passwords 


Users  may  provide  <accessPasswords> . If  the  information  is  provided,  the 
passwords  will  be  sent  to  the  Responder  in  the  <accessPasswords>  parameter. 

10.2.12.3  Anonymous  User  Convention 

A commonly  defined  "anonymous  user"  convention  is  to  be  provided  for  all 
systems  that  choose  to  support  this  capability.  The  access  available  to  that 
user  is  locally  determined.  The  <InitiatorIdentity>  value  to  be  used  is  ANON, 
encoded  as  an  <IA5String>.  Any  password  should  succeed. 

10.2.12.4  Implementation  Responsibilities 


It  is  the  responsibility  of  each  local  system  to  provide  security  for  its  own 
real  filestore.  Encryption  of  passwords  will  not  be  done  by  FTAM. 

A user  of  the  file  service  must  be  known  by  the  Responder.  "Known"  is  defined 
by  the  local  Filestore,  and  is  dependent  on  the  level  of  security  provided  by 
the  local  Filestore. 

10.2.13  Negotiation 

The  guidelines  for  negotiation  that  have  been  agreed  upon  are  outlined  in 
table  10.2. 
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Tbl.  10.2  FTAM  negotiation  rules 


Service  or  Parameter 

Depends  on  or  may  be  negotiated 
down  by: 

F- INITIALIZE 

Req . Pres . ContextMgmt 
Req.Func.  Unit 

Success  or  failure. 

Negotiated  by  subset  (as  per  DIS 
8571/3  section  10.3). 

(Affects  session  functional  units.) 

Req.Attr.  Groups 
Req . Comm . Quality 
of  services 
Req . ContentTypeList 

Negotiated  by  subset. 

Reference  session. 
Negotiated  by  subset. 

F- SELECT 

Attributes 

Only  by  <filename>. 

N.B.  The  <filename>  on  response  and 
confirm  must  be  that  of  an  existing 
virtual  file. 

Requested  Access 

Negotiated  by  subset  (in  case  of 
complete  or  partial  success),  must 
be  consistent  with  Functional  Units 
negotiated,  access  control  attribute, 
and  permitted  actions  attribute. 

F- CREATE 

Consistent  with  Functional  Units. 

Initial  attributes 

1.  The  attributes  returned  are  within 
the  subset  negotiated  at 
initialization. 

2.  The  individual  attribute  values 
returned  must  be  consistent  with 
negotiation/ranges  for  that  attribute 

3.  The  Responder  returns  values  for 
all  attributes  which  differ  from  the 
actual  request. 

Requested  Access 

As  in  F-SELECT. 

F- DELETE 

Consistent  with  Functional  Units. 

F-READ-ATTR 

Consistent  with  Functional  Units, 

F- CHANGE -ATTR 

service  class,  and  requested  access. 
As  for  F- READ -ATTRIBUTE. 

(Continued  on  next  page.) 
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Tbl.  10.2  FTAM  negotiation  rules,  continued 


Attributes 

If  any  attribute  cannot  be 
successfully  changed,  then  an  error 
more  severe  than  warning  should 
be  returned  and  no  attribute 
should  be  changed. 

F-OPEN 

Processing  Mode 

Not  Negotiated.  Must  be  consistent 
with  Functional  Unit  and  Requested 
Access  negotiated,  with  the  permitted 
actions  attribute,  and  with  the 
contents  type  name. 

Contents  Type 

As  defined  in  the  DIS. 

Concurrency  Control 

More  restrictive  than  the  concurrency 
control  of  F- SELECT;  consistent 
with  the  concurrency  control  of 
other  users. 

F- BEGIN -GROUP 

Consistent  with  Functional  Units  and 
F-END-GROUP  service  class. 

F- LOCATE 

Consistent  with  Functional  Units, 
F-ERASE,  requested  access  (and 
therefore  with  permitted  actions) 
Service  Class  and 
Processing  Mode. 

F-READ 

F-WRITE 

Functional  Units,  Service  Class  and 
number  of  bulk  data  transfers, 
Requested  Access  and  Processing  Mode. 

F - DATA/ F- DATA -END 
F- CANCEL 
F-TRANSFER-END 

Functional  Units  and 
Service  Class. 

10.2.14  Conformance 

This  section  gives  the  minimal  criteria  to  be  satisfied  by  implementations  of 
FTAM  to  be  conformant  to  these  agreements. 

Conformance  to  these  agreements  is  stated  in  terms  of  the  different  roles 
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occupied  by  FTAM  implementations.  The  interoperability  of  certain 

configurations  of  these  roles  motivates  this  approach.  Interoperable 
configurations  of  these  roles  is  given  in  section  10.2.14.1 

10.2.14.1  Interoperable  Configurations 

Any  implementation  conforming  to  this  specification  must  be  able  to  act  in  at 
least  one  of  the  following  role  combinations: 

1.  initiator  and  receiver, 

2.  initiator  and  sender, 

3.  responder  and  sender,  or 

4.  responder  and  receiver. 

Minimal  implementations  of  combination  1 will  interoperate  with  minimal 
implementations  of  combination  3.  Minimal  implementations  of  combination  2 
will  interoperate  with  minimal  implementations  of  combination  4. 

Any  implementations  of  roles  1 and  3 will  be  able  to  interoperate  at  the 
intersection  of  their  capabilities  (which  will  be  at  least  the  minimal 
capabilities  described  in  sections  10.2.14.3  to  10.2.14.8).  Any 

implementations  of  roles  2 and  4 will  be  able  to  interoperate  at  the 
intersection  of  their  capabilities  (which  will  be  at  least  the  minimal 
capabilities  described  in  sections  10.2.14.3  to  10.2.14.8). 

These  role  combinations  and  interoperability  are  shown  in  the  table  below. 


Tbl.  10.3  Interoperable  configurations 


Initiator 

Responder 

sender 

receiver 

sender 

receiver 

Initiator 

sender 

X 

receiver 

X 

Responder 

sender 

X 

receiver 

X 

10.2.14.2  Relationship  to  ISO  8571 --The  FTAM  Standard 

Any  implementation  in  conformance  to  ISO  8571  (as  defined  in  ISO  8571/4 
section  21  (Conformance)),  in  addition  to  the  implementation  of  the  minimal 
protocols  and  roles  enumerated  in  sections  10.2.14.3  to  10.2.14.8,  is 
considered  to  be  in  conforance  with  these  agreements.  Any  implementation 


61 


violating  any  of  the  conformance  statements  in  ISO  8571/4  is  considered  to  be 
in  violation  of  these  agreements. 

10.2.14.3  Requirements  for  Document  Type  Support 

The  document  type  NBS-1  shall  be  supported  for  purposes  of  transfer  and 
storage.  The  details  regarding  support  for  NBS-1  in  the  FTAM  dialogue  are 
given  in  sections  10.2.14.6  and  10.2.14.7. 

Support  of  document  types  other  than  NBS-1  (including  document  types  defined 
elsewhere  in  these  agreements  or  registered  by  authorities  other  than  the  NBS) 
are  not  required  by  these  agreements.  However,  for  the  support  for  any 

document  type  these  agreements  require  that  the  mechanisms  for  referencing 
those  document  types  in  the  protocol  be  consistent  with  the  protocol  in  both 
state  and  encoding.  Support  for  document  types  described  in  these  agreements 
also  entails  support  for  : 

o the  semantics  given  in  their  description, 

o the  preferred  transfer  syntax  (via  the  designated  transfer  syntax  name 
and  the  name  "{ISO  standard  8825},"  and 

o the  transfer  of  that  document  type  under  access  context  US 
(unstructured) . 

Support  for  other  document  types  is  not  required  by  these  agreements. 

10.2.14.4  Initiators 

Every  implementation  of  an  FTAM  initiator  shall  support: 

o the  kernel  protocol  and  its  mandatory  parameters  with  minimum 
ranges  [Minimum  required  ranges  are  specified  in  section 
10.2.14.8. ] , 

o the  grouping  protocol  and  the  threshold  parameter  with  a value 
of  2 for  use  in  the  file  transfer  class, 

o at  least  one  of  the  read  or  write  protocols  [Specific 
conformance  for  reading  and  writing  is  defined  in  sections 
10.2.14.6  and  10.2.14.7.], 

and  support  the  applicable  procedures  defined  in  ISO  8571/4  sections  8.1  (FTAM 
regime  establishment),  8.2  (FTAM  regime  termination),  8.3  (File  selection), 

8.4  (File  deselection),  8.9  (File  open),  8.10  (File  close),  8.11  (Begin  group) 
and  8.12  (End  group),  and  10  (File  general  actions).  To  support  the  above 
protocols  and  procedures  the  implementation  shall  be  able  to: 

o request  the  kernel,  grouping  and  at  least  one  of  the  read  or 
write  functional  units. 
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o request  the  Creliable  file  service>  (but  not  necessarily  any 
error  control  procedures)  with  the  "service  level"  parameter, 

o request  the  file  transfer  class  with  the  "service  class" 

parameter, 

o request  optional  functional  units  consistently  from  those 

defined  for  the  file  transfer  service  class, 

o request  the  document  type  NBS-1  using  the  "document  type  name" 
form  of  the  contents  type  parameter,  and 

o request  a "communication  quality  of  service"  consistent  with  the 
transport  definition  in  these  agreements 

as  part  of  the  filestore  initialization  procedures  in  ISO  8571/4  section  8.1, 
FTAM  regime  establishment. 

Initiators  must  be  able  to  operate  under  all  circumstances  if  the  above 
minimum  values  are  successfully  negotiated  and  returned  on  an  F- 
INITIALIZEresponse  PDU.  Initiators  must  be  able  to  operate  with  any  downward 
negotiation  of  requested  parameter  values  as  described  in  section  10.2.13. 

Should  the  supporting  services  break  down,  such  that  FTAM  communication  is 
impossible,  the  FTAM  protocol  machine  shall  notify  the  user  with  an  <F-P- 
ABORT  indication>  and  <diagnostic>  with  identifier  1011.  Any  known  "further 
details"  are  recommended. 

10.2.14.5  Responders 

Every  implementation  of  an  FTAM  responder  shall  support; 

o the  kernel  protocol  and  its  mandatory  parameters  with  minimum 
ranges  [Minimum  required  ranges  are  specified  in  section 
10.2.14.8.], 

o the  grouping  protocol  and  the  threshold  parameter  with  a value 
of  2 for  use  in  the  file  transfer  class, 

o at  least  one  of  the  read  or  write  protocols  [Specific 
conformance  for  reading  and  writing  is  defined  in  sections 
10.2.14.6  and  10.2.14.7.], 

and  support  the  applicable  procedures,  defined  in  ISO  8571/4  sections  9.1 
(FTAM  regime  establishment),  9.2  (FTAM  regime  termination),  9.3  (File 
selection),  9.4  (File  deselection),  9.9  (File  open),  9.10  (File  close),  9.11 
(Begin  group)  and  9.12  (End  group),  and  10  (File  general  actions).  To  support 
the  above  protocols  and  procedures  the  implementation  shall  be  able  to: 

o accept  requests  for  the  kernel,  grouping  and  at  least  one  of  the 
read  or  write  functional  units, 


63 


o accept  requests  the  <Reliable  File  Service>  (but  not  necessarily 
any  error  control  procedures)  with  the  "service  level" 
parameter, 

o accept  requests  for  the  file  transfer  class  with  the  "service 
class"  parameter, 

o accept  requests  for  optional  functional  units  consistently  from 
those  defined  for  the  file  transfer  service  class  and  consistent 
with  its  supported  roles  as  specified  in  section  10.2.13.1, 

o request  the  document  type  NBS-1  using  the  "document  type  name" 
form  of  the  contents  type  parameter,  and 

o accept  requests  for  a "communication  quality  of  service" 

consistent  with  the  transport  definition  in  these  agreements 

as  part  of  the  filestore  initialization  procedures  in  ISO  8571/A  section  9.1, 
FTAM  regime  establishment. 

Responders  must  be  able  to  operate  under  all  circumstances  if  the  above 
minimum  values  are  requested  on  an  F-INITIALIZErequest  PDU.  Responders  must 
not  negotiate  upward  in  the  sense  described  in  section  10.2.13. 

Each  responder  shall  support,  for  purposes  of  both  communication  and 
processing,  the  kernel  and  storage  groups  of  attributes.  A value  shall  always 
be  available  for  the  kernel  attributes.  (For  the  storage  attributes  a value 
of  "no  value  available"  may  be  the  only  applicable  value.) 

Responders  must  complete  each  action  requested  and  supported  in  a manner 
consistent  with  its  description  in  ISO  8571/2  sections  6 (Actions  on  complete 
files)  and  7 (Actions  for  file  access),  and  must  interpret  each  supported 
attribute  in  a manner  consistent  with  its  definition  in  ISO  8571/2  section  8 
(File  attributes). 

Under  circumstances  where  actions  cannot  be  carried  out  either  as  requested  or 
consistently  with  ISO  8571/2  sections  6 (Actions  on  complete  files)  and  7 
(Actions  for  file  access),  the  responder  must  return  at  least  one  diagnostic 
indicating: 

o if  the  failure  was  due  to  either  a protocol  or  filestore 
failure,  and  then; 

--  precisely  which  action  failed, 

--  at  least  one  of  the  parameters  that  could  not  be  accommodated 
with  the  diagnostic  type  indicating  at  least  the  degree  of 
failure,  as  given  by  the  action  and  state  result  parameters;  or 

o that  the  failure  was  due  to  unforeseen  system  shutdown. 

Should  the  supporting  services  break  down,  such  that  FTAM  communication  is 
impossible,  the  FTAM  protocol  machine  shall  notify  the  user  with  an  <F-P- 
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ABORT  indication>  and  <diagnostic>  with  identifier  1011.  Any  known  "further 
details"  are  recommended. 

10.2.14.6  Senders 

Every  implementation  of  an  FTAM  sender  shall  support  the  read  functional  unit 
as  responder  or  the  write  functional  unit  as  initiator,  and  support  the 
applicable  procedures  defined  in  ISO  8571/4  sections  11  (State  of  the  bulk 
data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  15  (Bulk 
data  transfer  sending  entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  send  files  of 
the  NBS  document  type  NBS-1  (UNDEF)  and  shall  be  able  to  send  them  as  user 
data  in  PPDUs  in  blocks  of  no  more  than  7168  octets. 


10.2.14.6.1  Initiator  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  initiator  shall 
support : 

o the  write  functional  unit  and  protocol,  and 


o for  the  document  type  NBS-1  the  following  bulk  data  transfer 
specification  parameter: 


FADU  operation  replace 

FADU  identity  first 

Access  context  US 


and  support  the  applicable  procedures,  defined  in  ISO  8571/4  section  13  (Bulk 
data  transfer  initiating  entity  actions). 

10.2.14.6.2  Responder  Senders 


Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  responder  shall 
support: 

o the  read  functional  unit  and  protocol,  and 

o for  the  document  type  NBS-1  the  following  bulk  data  transfer 
specification  parameter: 


FADU  identity  first 
Access  context  US 


and  support  the  applicable  procedures,  defined  in  ISO  8571/4  section  14  (Bulk 
data  transfer  responding  entity  actions). 

10.2.14.7  Receivers 


Every  implementaton  of  an  FTAM  receiver  shall  support  the  read  functional  unit 
as  initiator  or  the  write  functional  unit  as  responder,  and  support  the 
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applicable  procedures,  defined  in  ISO  8571/4  sections  11  (State  of  the  bulk 
data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  16  (Bulk 
data  transfer  receiving  entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  receive  files 
of  the  NBS  document  type  NBS-1  (UNDEF ) and  shall  be  able  to  receive  them  as 
user  data  in  PPDUs  in  blocks  of  at  least  than  7168  octets. 

10.2.14.7.1  Initiator  Receivers 


Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  initiator  shall 
support: 

o the  read  functional  unit  and  protocol,  and 

o for  the  document  type  NBS-1  the  following  bulk  data  transfer 

specification  parameter: 

FADU  identity  first 
Access  context  US 

and  support  the  applicable  procedures,  defined  in  ISO  8571/4  section  13  (Bulk 
data  transfer  initiating  entity  actions). 

10.2.14.7.2  Responder  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  responder  shall 
support: 


o the  write  functional  unit  and  protocol,  and 


o 

for  the  document  type  NBS-1 
specification  parameter: 

the  following  bulk  data  transfer 

FADU  operation 

replace 

FADU  identity 

first 

Access  context 

US 

and  support  the  applicable  procedures,  defined  in  ISO  8571/4  section  14  (Bulk 
data  transfer  responding  entity  actions). 

10.2.14.8  Minimum  Ranges 

Any  implementation  of  any  conformant  FTAM  configuration  shall  be  able  to 
receive  and  meaningfully  process  all  mandatory  parameters  for  all  functional 
units  supported  as  well  as  the  diagnostic  parameter  within  at  least  the 
minimum  ranges  of  values  given  in  table  10.4.  (A  conforming  implementation 
may  support  a broader  range  of  values  for  any  parameter.) 
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Tbl.  10.4  Required  minimal  parameter  support 


Parameter 

Minimum  Range 

diagnostic 

Values  as  specified  in  ISO  8571/3  Annex  A 
(Diagnostic  parameter  values)  tables  42, 
43  and  45  which  correspond  directly  to 
mandatory  parameters. 

action  result 

All  values. 

state  result 

All  values. 

^INITIALIZE 

functional  units^ 

"read"  (for  initiator/receivers  and 
responder/ senders ) 
or 

"write"  (for  initiator/ senders  and 
responder/ receivers ) . 

presentation 

context  management^ 

"Not  required." 

all  others 

As  specified  in  sections  10.2.14.4  and 
10.2.14.5  above. 

F SELECT 

attributes 

Only  filename  is  used  with  a minimum 
supportable  length  of  8 characters.  Any 

other  attribute  supported  for  other 
services  must  have  minimum  supported 
lengths  as  in  ISO  8571/2  section  11 
(Minimum  attribute  ranges)  table  2. 

requested  access 

"read"  for  initiator  receivers 
"read"  for  responder  senders 
"read"  for  initiator  senders 
"read"  for  responder  receivers 

F_0PEN 

processing  mode 

"read"  for  initiator  receivers 
"read"  for  responder  senders 
"replace"  for  initiator  senders 
"replace"  for  responder  receivers 

content  type 

"NBS-1" 

(Continued  on  next  page.) 
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Tbl . 10.4  Required  minimal  parameter  support,  continued 


Parameter 


F_READ 
F WRITE 


Minimum  Range 


FADU  operation  "read11  for  initiator  receivers 

"read"  for  responder  senders 

"read"  for  initiator  senders 

"replace"  for  responder  receivers 


FADU  identity  "first" 
access  context  "US" 


F BEGIN  GROUP 


threshold 


3 


For  file  transfer  (a  minimal  required 
function)2 . 


1 The  parameters,  functional  units,  and  presentation  context  management  are 
not  ordered,  so  "minimum  value"  cannot  be  formally  defined.  The  above 
values  are  those  required  for  conformance  to  these  agreements  but  no 
value  conformant  to  ISO  8571  for  use  in  other  applications  is  regarded  to 
be  in  violation  of  these  agreements. 

2.  Other  functional  units  (and  service  classes)  for  defined  implementations 
may  also  be  valid  provided  that  they  are  implemented  in  accordance  with 
these  agreements,  specifically  section  10.2.14.8. 

^ Every  implementation  must  support  the  threshold  value  2 to  provide  the 
basic  required  function  of  file  transfer;  any  other  value  in  other 
applications  is  acceptable. 

For  any  other  supported  parameters,  minimum  ranges  are  taken  from  the  minimum 
ranges  for  the  attribute  corresponding  to  each  as  in  ISO  8571/2  table  2. 

10.2.14.9  Meaning  for  Support  of  Options  Defined  in  These  Agreements 

This  section  describes  requirements  and  options  for  service  classes  defined  bv 
these  agreements,  as  well  as  specific  document  types,  attributes  and 
parameters  and  their  ranges.  General  recommendations  in  accordance  with  DIS 
8571/4  section  21.1  are  given  also;  those  definitions  apply  to  any  defined 
options . 


10.2.14.9.1  Service  Classes 
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The  following  service  classes  are  defined  individually  for  implementations. 
Note  that  no  defined  implementation  is  precluded  from  supporting  more  than  one 
service  class. 

o File  access 

o File  management 

o Unconstrained 

Support  of  a service  class  requires  adherence  to:  1.  its  definition  in  DIS 

8571/3  section  8 and  any  related  procedures  in  DIS  8571/4  sections  8-17,  2. 

requirements  given  in  section  10.2.1-10.2.14  of  these  agreements,  and  3. 
requirements  for  parameter  and  attribute  support  as  defined  in  section 
10.2.14.8. 


10.2.14.9.2  General  Requirements  for  Implementations  Defined  in  Section 

10.2.14.10 


o Implementations  will  support  the  Reliable  Service  level. 

o Implementations  will  be  able  to  act  both  as  initiators  and 

responders . 

o Implementations  that  support  either  the  limited  file  management 
or  both  limited  file  management  and  enhanced  file  management 
must  support  both  the  Storage  and  Security  attribute  groups. 

o Implementations  must  support  diagnostics  as  described  in  section 
10.2.9  of  these  agreements. 

0 Implementations  that  support  the  file  access  service  class  will 
support  the  hierarchical  file  model  and  support  an  arc  length 
greater  than  one. 

10.2.14.9.3  Recommended  Use  of  Lower  Layer  Services 

o Implementations  will,  additionally,  support  the  mapping  of  the 
F- CANCEL  PDU  on  P- RESYNCHRONIZE. 

o Support  for  the  Presentation  Context  Management  functional  unit 
is  not  required. 

o Implementations  will  support  the  Session,  Presentation,  and  ACSE 
requirements  as  stated  in  sections  8,  11,  and  12. 

10.2.14.9.4  Document  Type  Requirements  for  Implementations  Defined  in  Section 

10.2.14.10 

It  is  recommended  that  implementations  conformant  to  these  agreements  also 

implement  the  following  document  types  with  the  caveats  and  procedures  given. 

Those  document  types  are  defined  in  Appendix  D of  these  agreements. 

o NBS-2 
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Caveat:  NBS-2  is  included  only  to  allow  compatibility  with  file 

systems  storing  Phase  1 files, 
o NBS-4 

o NBSm6 

o NBS-7 

Note:  Support  of  this  document  type  entails  the  naming  of  FADUs  by 

their  position  in  preorder  traversal.  NBS-7  applies  only  to  file 
access. 

Caveat:  Other  methods  of  naming  FADUs  depend  on  the  system, 

application,  and  specific  file,  and  as  such  are  not  described  here, 
o NBS-5 

Note:  Support  for  8859  strings  and  their  interpretation  as  defined 

in  section  10.2.7.1  of  these  agreements. 

Support  of  the  following  document  types  is  recommended  with  qualifications. 

o NBS-8 

Note:  Only  when  the  file  access  service  class  is  implemented, 

o NBS-9 

Note:  Only  when  the  file  management  service  class  is  implemented. 

Support  of  NBS-2, 3, 4, 5 require  the  ability  for  transfer  or  access  using 
transfer  syntax  TS-1. 

Support  for  any  document  type  requires  the  ability  to  transfer  and  store  the 
abstract  syntax  given  in  its  definition.  These  agreements  do  not  specify 
techniques  or  formats  for  storage. 

Caveat:  Specific  abstract  and  transfer  syntaxes  for  the  parametrized  document 

types  NBS-6,7,8  are  not  specified  in  these  agreements. 

Any  document  type  supported  must  be  identifiable  by  its  document  type  name  as 
given  in  Appendix  D and,  where  defined,  the  parameterization  scheme  given  in 

section  10.2.7  of  these  agreements. 

10.2.14.9.5  Recommended  Parameter  for  Implementations  Defined  in  Section 

10.2.14.10 


o Implementations  will  not  use  CCR  parameters. 

o Implementations  will  use  the  contents  type  list  parameter  on  the 

F-INITIALIZE  service  element. 

o Implementations  will  use  the  Account  Parameter  on  the  F- 

INITIALIZE  request  PDU. 

o Implementations  will  support  the  Diagnostic  Parameter  as  stated 
in  section  10.2.9  of  these  agreements. 

o Implementations  will  use  the  Charging  Parameter  on  the  F- 

TERMINATE  Service  Element. 
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o Implementations  will  use  the  Identity  of  Initiator  Parameter  on 
the  F- INITIALIZE  Service  Element.  Use  must  be  consistent  with 
section  10.2.12  of  these  agreements. 

o Implementations  are  not  precluded  from  using  other  parameters 
for  Security  and/or  acounting. 

10.2.14.9.6  Parameter  Ranges  for  Implementations  Defined  in  Section 

10.2.14.10 


Parameter  ranges  for  implementations  defined  in  section  10.2.14.10  are  as 
stated  for  primitive  data  types  in  10.2.7  of  these  agreements. 

10.2.14.9.7  File  Attribute  Support  for  Implementations 

Implementations  defined  in  section  10.2.14.10  will  support  file  attributes  in 
the  following  ways. 


o 

If  an  attribute  is  "supported"  it  implies  a 

value  will  be 

returned  other  than  the  value  "no  value  available," 

and  the 

value  will  follow  the  rules  as  stated  in  these  agreemnts  and  in 

FTAM  8571  part  2. 

o 

If  an  attribute  is  "optionally  supported"  a value 

of 

"no  value 

available"  may  be  returned. 

o 

If  an  attribute  is  "not  supported"  a value  will  not 

be 

returned . 

Kernel 

Group 

1. 

Filename  - supported 

2. 

Contents  Type  - supported 

Storage  Group 

1. 

storage  account 

2. 

date  and  time  of  creation 

3. 

date  and  time  of  last  modification 

4. 

date  and  time  of  last  read  access 

5. 

date  and  time  of  last  attribute  modification 

6. 

Identity  of  Creator 

7. 

Identity  of  Last  Modifier 

8. 

Identity  of  Last  Reader 

9. 

Identity  of  Last  Attribute  Modifier 

10. 

File  Availability  - supported 

11. 

Permitted  actions  - supported 

12. 

Filesize  - supported 

13. 

Future  Filesize 

Security  Group 
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1 . access  control  - supported 

2.  encryption  name 

3.  legal  qualifications 


Private  Group 

1.  Private  use  - not  supported 
10.2.14.10  Implementation  Classes 

The  following  implementation  classes  (profiles)  are  defined: 

Tl:  Simple  File  Transfer 

T2:  Positional  File  Transfer 

T3:  Full  File  Transfer 

Al:  Positional  File  Access 

A2:  Full  File  Access 

Ml:  File  Store  Management 

Notes: 

1.  The  File  Store  Management  class  is  only  to  be  implemented  in  conjunction 
with  one  of  the  Transfer  or  Access  classes. 

2.  Class  T2  is  a subset  of  T3»  Al  and  Tl  are  subsets  of  A2  and  T2, 
respectively. 
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Tbl.  10.5  Implementation  class  support  requirements 


FU 

T 

Service  Class 
M A 

T&M 

UNCST 

A1,A2 

Kernel 

T1,T2,T3 

A2 

T1,T2,T3 

Read 

T1,T2,T3 

A2 

A1,A2 

T1,T2,T3 

Write 

T1,T2,T3 

A2 

A1,A2 

T1,T2,T3 

Limited  File  Mgmnt. 

Ml 

Ml 

Enhanced  File  Mgmnt. 

Ml 

Ml 

Graphics 

T1,T2,T3 

T1,T2,T3 

File  Access 

A2 

Document  Types 

NBS-1 

T1,T2,T3 

T1,T2,T3 

NBS-2 

T1,T2,T3 

T1,T2,T3 

NBS-3 

T1,T2,T3 

T1,T2,T3 

NBS-4 

T2,T3 

A2 

A1,A2 

T2,T3 

NBS-5 

T2,T3 

A2 

A1,A2 

T2,T3 

NBS-d 

T2,T3 

A2 

A1,A2 

T2,T3 

NBS-w 

T2,T3 

A2 

A1,A2 

T2,T3 

NBS-8 

T3 

A2 

A2,T3 

NBS-9 

Ml 

Ml 

The  Transfer,  Access,  and  Management  classes  as  defined  above  correspond  to 
the  SPAG  FTAM  profiles  as  described  in  the  "Guide  to  the  Use  of  Standards,"  as 
follows. 


Tbl.  10.6  Profile  name  relations  - NBS/OSI  to  SPAG 


Implementation  Class 

SPAG  Profile 

T1 

Alll 

T2 

A112 

T3 

A113 

A1 

A122 

A2 

A123 

Ml 

A131 
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For  further  details  on  which  parameters  and  file  attributes  are  supported  for 
the  SPAG  FTAM  profiles,  see  the  "Guide  to  the  Use  of  Standards." 
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11.  ISO  PRESENTATION  LAYER 


The  Presentation  services  are  defined  to  meet  the  needs  of  many  applications. 
The  Presentation  service  is  defined  in  ISO  DIS  8822  and  the  Presentation 
protocol  is  defined  in  ISO  DIS  8823.  General  agreements  about  the 
implementation  of  the  Presentation  layer  are  documented  below  in  section  11.1, 
followed  by  agreements  related  to  specific  applications. 

Note:  When  the  service  definition  and  protocol  specification  achieve 
International  Standard  status  in  ISO,  these  agreements  will  be  aligned  with 
the  ISO  documents. 

11.1  GENERAL 


o The  services  of  the  Presentation  kernel  functional  unit  are  used 
as  specified  in  ISO  DIS  8822  and  8823  and  must  be  implemented. 

o Presentation  connections  always  use  multiple  presentation 

context  mode. 

o Multiple  encoding  of  user  data  on  connect  requests  is  not 
required. 

o The  following  abstract  syntaxes  must  be  supported. 

ISO  8650-2-ACSE  1 (ACSE  PCI) 

o Abstract  Syntaxes  are  identified  by  registered  name. 

o The  following  Transfer  Syntaxes  must  be  supported  for  all 

mandatory  and  defined  abstract  syntaxes. 

NBS-TS1  (application  of  ASN.l  Encoding  Rules) 

o Transfer  Syntaxes  are  identified  by  registered  name. 

o A mandatory  functional  unit  is  one  which  must  be  implemented  by 
the  service  provider. 

o An  optional  functional  unit  is  one  which  may  be  implemented  by 

the  service  provider,  but  irrespective  of  whether  it  is 

implemented  or  not,  it  must  recognize  and  respond  to  correct 
requests  for  its  use. 

11.2  PRESENTATION  REQUIREMENTS  FOR  FTAM 

o The  following  abstract  syntaxes  must  be  supported. 

ISO  8571-FTAM  (including  ISO  8571-FADU) 

NBS-AS1  (primitive  data  types) 
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o In  addition,  the  following  optional  abstract  syntaxes  may  be 
implemented. 

NBS-AS2  (floating  point  numbers) 

NBS-AS3  (file  directories) 

o An  implementation  must  support  at  least  three  simultaneous 

presentation  contexts. 

o All  session  requirements  for  FTAM  are  reflected  in  the 

Presentation  layer. 
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12.  ASSOCIATION  CONTROL  SERVICE  ELEMENT 


The  ACSE  service  is  defined  to  meet  the  needs  of  many  applications.  The  ACSE 
service  is  defined  in  ISO  DIS  8649/2  and  the  ACSE  protocol  is  defined  in  ISO 
DIS  8650/2.  General  agreements  about  implementation  of  ACSE  are  documented 
below  in  section  12.1,  followed  by  agreements  related  to  specific 
applications . 

Note:  When  the  service  defintion  and  protocol  specification  achieve 

International  Standard  status  in  ISO,  the  agreements  will  be  aligned 
with  the  ISO  documents. 

12.1  GENERAL 


o All  services  specified  in  ISO  DIS  8649/2  must  be  implemented. 

o A mandatory  parameter  is  one  that  must  be  implemented  in  the 

protocol  by  the  service  provider.  The  service  user  must  always 
make  a value  for  the  parameter  available. 

o An  optional  parameter  is  one  that  must  be  implemented  in  the 

protocol  by  the  service  provider,  but  the  user  has  the  option  of 
making  available  or  not  making  available  a value  for  the 
parameter. 

12.2  APPLICATION  ENTITY  TITLES 


o An  Application  Entity  Title  will  name  a specific  Application 
Entity  Instance  on  a specific  end  system. 

o The  naming  of  Application  Entities  is  external  to  the 

specification. 

o Application  Entity  Titles  may  be  mapped  many-to-one  to  PSAP 

addresses . 

o An  Application  Entity  Title  is  a registered  name  of  type  Object 
Identifier. 

12.3  ETAM  REQUIREMENTS  OF  ACSE 

o The  Application  context>  value  <IS0  FTAM>  is  used  to  specify 
the  use  of  ACSE  and  the  FTAM  ASE. 


77 


13.  X. 400  BASED  MESSAGE  HANDLING  SYSTEM 


13.1  INTRODUCTION 


This  is  an  implementation  agreement  developed  by  the  Implementor's  Workshop 
sponsored  by  the  U.S.  National  Bureau  of  Standards  to  promote  the  useful 
exchange  of  data  between  devices  manufactured  by  different  vendors.  This 
agreement  is  based  on,  and  employs  protocols  developed  in  accord  with,  the  OS I 
Reference  Model.  While  this  agreement  introduces  no  new  protocols,  it 
eliminates  ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a Message  Handling  System  (MHS)  based 
on  the  X. 400-series  of  Recommendations  (1984)  from  the  CCITT.  Figure  13.1.1 
displays  the  layered  structure  of  this  agreement. 

This  agreement  can  be  used  over  any  transport  profile.  In  particular,  this 
profile  can  be  used  over  the  transport  protocol  class  0 used  over  CCITT  X.25, 
described  in  section  7.2  of  this  document.  In  addition,  this  profile  can  be 
used  over  the  transport  profiles  used  in  support  of  MAP  (Manufacturing 
Automation  Protocol)  or  TOP  (Technical  and  Office  Protocols).  Note  that  the 
MAP  or  TOP  environment  must  support  the  reduced  Basic  Activity  Subset  (BAS)  as 
defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  directory  and  routing  services.  A 
Directory  Service  is  to  be  provided  for  each  (vendor-specific)  domain.  Except 
insofar  as  they  must  be  capable  of  providing  addressing  and  routing  described 
hereunder,  these  services  and  associated  protocols  are  not  described  by  this 
agreement . 

The  material  on  PRMD-PRMD  message  transfer  in  this  implementation 
specification  is  intended  to  be  stable  enough  to  provide  a reliable  guide  to 
implementation  of  X.400.  The  material  on  ADMD-PRMD  and  ADMD-ADMD  is 
incomplete  and  serves  as  an  indication  of  direction. 
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User  Agent  Layer 

CCITT  X. 420 

Message  Transfer  Agent  Layer 

CCITT  X. 411 

Reliable  Transfer  Service  Layer 

CCITT  X. 410 

Presentation  Layer 

CCITT  X.410  sec.  4,2 

Session  Layer 

CCITT  X. 225 

Fig.  13.1.1  The  layered  structure  of  this  implementation  agreement 
13.2  SCOPE 

This  agreement  applies  to  Private  Management  Domains  (PRMDs)  and 
Administration  Management  Domains  (ADMDs).  Three  boundary  interfaces  are 
specified: 

1.  PRMD  to  PRMD; 

2.  PRMD  to  ADMD; 

3.  ADMD  to  ADMD. 

In  case  1,  the  PRMDs  do  not  make  use  of  MHS  services  provided  by  an  ADMD  . In 
cases  2 and  3,  UAs  associated  with  an  ADMD  can  be  the  source  or  destination 
for  messages.  Furthermore,  in  cases  2 and  3,  an  ADMD  can  serve  as  a relay 
between  MDs.  Figure  13.2.1  illustrates  the  interfaces  to  which  the  agreement 
applies . 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (PI)  and  the 
Interpersonal  Messaging  Protocol  (P2)  are  beyond  the  scope  of  this  agreement. 
Issues  arising  from  the  use  of  other  protocols  or  relating  to  PI  components  in 
support  of  other  protocols  are  outside  the  scope  of  this  document.  This 
agreement  describes  the  minimum  level  of  services  provided  by  Management 
Domains  (MDs).  Provision  for  the  use  of  the  remaining  services  defined  in  the 
X.400  Series  of  Recommendations  is  outside  the  scope  of  this  document. 

This  agreement  does  not  cover  message  exchange  between  communicating  entities 
within  a domain  even  if  these  entities  communicate  via  PI  or  P2.  Bilateral 
agreements  between  domains  may  be  implemented  in  addition  to  the  requirements 
stated  in  this  document.  Conformance  to  this  agreement  requires  the  ability 
to  exchange  messages  with  conforming  domains  that  have  made  no  bilateral 
agreements . 


79 


PRMD  = Private  Management  Domain 
ADMD  = Administration  Management  Domain 

A 

i 


Fig.  13.2.1  This  agreement  applies  to  the  interface  between: 

(A)  PRMD  and  PRMD;  (B)  PRMD  and  ADMD;  (C)  ADMD  and  ADMD 

13.3  PRMD  to  PRMD 

This  section  is  limited  in  scope  to  issues  arising  from  the  direct  connection 
(interface  A in  Figure  13.2.1)  of  two  PRMDs.  "Direct"  means  that  no  ADMD 
provides  MHS  services  to  facilitate  message  interchange.  "Direct"  does  not 
exclude  those  instances  for  which  ADMDs  provide  lower  layer  services  (e.g., 
X.25).  Figure  13.3.1  schematically  represents  the  scope  of  this  section. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL  (Message 
Transfer  Layer)  services,  protocol  elements,  recommended  practices  and 
constraints.  In  particular,  this  section  addresses  the  PI  and  P2  protocols 
and  their  related  services  in  a direct  connection  environment.  This  section 
describes  the  minimum  level  of  services  provided  by  a PRMD.  Provision  for  the 
use  of  the  remaining  services  defined  in  the  X.400  Series  of  Recommendations 
is  beyond  the  scope  of  this  section. 
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Fig.  13.3.1  Interconnection  of  private  domains 

13.3.1  Service  Elements  and  Optional  User  Facilities 

This  section  identifies  those  service  elements  and  optional  user  facilities 
that  must  be  provided  in  support  of  PI  and  P2. 

13.3.1.1  Classification  of  Support  for  Services 

The  classification  of  UA  and  MT-Service  elements  is  used  to  define 
characteristics  of  equipment.  Equipment  can  claim  SUPPORT  or  NON-SUPPORT  of  a 
Service;  in  the  case  of  UA-service  elements,  a separate  classification  is 
given  for  Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the  service,  in  this 
case,  the  MTL  or  the  UAL.  The  service  user  is  either  the  MHS  user  or  the  UAL. 
The  classification  of  provider  and  user  relates  to  the  sublayer  for  which  the 
service  element  is  defined. 

13.3.1.1.1  Support  (S) 

This  means  that: 

1 . The  service  provider  makes  the  service  element  available  to  the  service 
user. 

2.  The  service  user  gives  adequate  support  to  the  MHS  to  invoke  the  service 
element  or  makes  information  associated  with  the  service  element 
available. 

Support  for  Origination  means  that: 
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1.  The  service  provider  makes  the  service  element  available  to  the  service 
user  for  invocation. 

2.  The  service  user  gives  adequate  support  to  the  end  user  of  the  MHS  to 
invoke  the  service  element. 

Support  for  Reception  means  that  the  service  provider  makes  information 
associated  with  the  service  element  available  to  the  service  user. 

Note:  A UA-  or  MT-service  element  can  carry  information  from  originator  to 

recipient  only  if: 

o the  service  element  is  available  to  the  originator, 
o the  service  element  is  available  to  the  recipient,  and 
o all  intermediate  steps  carry  the  information. 

13.3.1.1.2  Non  Support  (N) 

This  means  that  the  service  provider  is  not  required  to  make  the  service 
element  available  to  the  service  user.  However,  the  service  provider  should 
not  regard  the  occurrence  of  the  corresponding  protocol  elements  as  an  error 
and  should  be  able  to  relay  such  elements.  Implementations  making  a profile 
available  should  indicate  deviations  (additions  or  deletions)  with  respect  to 
the  requirement  in  the  profile. 

13.3.1.1.3  Not  Used  (N/U) 

This  means  that  although  the  Recommendations  allow  this  service  element,  this 
profile  does  not  use  it. 

13.3.1.1.4  Not  Applicable  (N/A) 

This  means  that  this  service  element  does  not  apply  in  this  particular  case 
(for  originator  or  recipient). 

13.3.1.2  Summary  of  Supported  Services 

o Within  a PRMD,  a User  Agent  must  support  all  P2  BASIC  I PM 
Services  (X.400)  and  all  P2  ESSENTIAL  IPM  Optional  user 
facilities  (X.401)  subject  to  the  qualifiers  listed  in  Appendix 
A. 

o Within  a PRMD,  a MTA  must  support  all  BASIC  MT  Services  (X.400) 
and  all  ESSENTIAL  MT  optional  user  facilities  (X.401)  subject  to 
the  qualifiers  listed  in  Appendix  A. 

o No  support  is  required  of  the  additional  optional  user 
facilities  of  X.401. 
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13.3.1.3  MT  Service  Elements  and  Optional  User  Facilities 


Tables  13.3.1  through  13.3.3  show  the  message  transfer  (MT)  service  elements 
and  optional  user  facilities. 


Tbl.  13.3.1  Basic  MT  service  elements 


Support  (S)  or 

Service  Elements 

Non-support  (N) 

Access  Management 

N/U1 

Content  Type  Indication 

S 

Converted  Indication 

S 

Delivery  Time  Stamp  Indication 

S 

Message  Identification 

S 

Non-delivery  Notification 

S 

Original  Encoded  Information  Types  Indication  S 

Registered  Encoded  Information  Types 

N/U1 

Submission  Time  Stamp  Indication 

S 

Not  applicable  to  co-resident  UA  and  MTA. 
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Tbl.  13.3.2  MT  optional  user  facilities  provided  to  the 
UA-selectable  on  a per-message  basis 


MT  Optional  User  Facilities 

Categorization 

Support  (S)  or 
Non-support  (N) 

Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

S 

Deferred  Delivery 

E 

N2 

Deferred  Delivery  Cancellation 

E 

N2 

Delivery  Notification 

E 

S 

Disclosure  of  Other  Recipients 

E 

N3 

Explicit  Conversion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi -destination  Delivery 

E 

S 

Prevention  of  Non-delivery  Notification 

A 

N 

Probe 

E 

N4 

Return  of  Contents 

A 

N 

Tbl.  13.3.3  MT  optional  user  facilities  provided  to  the  UA 
agreed  for  a contractual  period  of  time 


MT  Optional  User  Facilities 

Categorization 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment 

A 

N 

Hold  for  Delivery 

A 

N/U 

Implicit  Conversion 

A 

N 

; Essential  optional  user  facility. 

; Additional  optional  user  facility. 

A local  facility  subject  to  qualifiers  in  Appendix  A. 

Support  not  required  for  an  originating  MT  user;  support  must  be  provided 
for  recipient  MT  users. 

Subject  to  qualifiers  in  Appendix  A. 
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13.3.1. A IPM  Service  Elements  and  Optional  User  Facilities 


Tables  13.3.4  through  13.3.6  show  the  IPM  service  elements  and  optional  user 
facilities . 


Tbl.  13.3.4  Basic  IPM  service  elements 


Service  Elements 

Origination 
by  UAs 

Reception 
by  UAs 

Access  Management 

N/U5 

N/U5 

Content  Type  Indication 

S 

S 

Converted  Indication 

N/A 

S 

Delivery  Time  Stamp  Indication 

N/A 

S 

Message  Identification 

S 

s 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

s 

S 

Types  Indication 

Registered  Encoded  Information  Types 

N/A 

N/A5 

Submission  Time  Stamp  Indication 

S 

S 

IP-message  Identification 

S 

S 

Typed  Body 

S 

S 

Does  not  apply  to  co-resident  UA  and  MTA. 


Tbl.  13.3.5  IPM  optional  facilities  agreed  for  a contractual 
period  of  time 


Service  Elements  Categorization 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment 

A 

N 

Hold  for  Delivery 

A 

N 

Implicit  Conversion 

A 

N 
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Tbl.  13.3.6  IPM  optional  user  facilities  selectable  on  a 
per-message  basis 


Origination 

Reception 

IPM  Optional  User  Facilities 

by  UAs 

by  UAs 

Alternate  Recipient  Allowed 

A (N) 

A (N) 

Authorizing  Users  Indication 

A (N) 

E (S 

Auto -forwarded  Indication 

A (N) 

E (S) 

Blind  Copy  Recipient  Indication 

A (N) 

E (S) 

Body  Part  Encryption  Indication 

A (N) 

E (S) 

Conversion  Prohibition 

E (S) 

E (S) 

Cross-referencing  Indication 

A (N) 

E (S) 

Deferred  Delivery 

E (N)6 

N/A 

Deferred  Delivery  Cancellation 

A (N/U)6 

N/A 

Delivery  Notification 

E (S) 

N/A 

Disclosure  of  Other  Recipients 

A (N) 

E (S) 

Expiry  Date  Indication 

A (N) 

E (S) 

Explicit  Conversion 

A (N) 

N/A 

Forwarded  IP-message  Indication 

A (N) 

E (S) 

Grade  of  Delivery  Selection 

E (S) 

E (S) 

Importance  Indication 

A (N) 

E (S) 

Multi-destination  Delivery 

E (S) 

N/A 

Multi -part  Body 

A (N) 

E (S) 

Non-receipt  Notification 

A (N) 

A (N) 

Obsoleting  Indication 

A (N) 

E (S) 

Originator  Indication 

E (S) 

E (S) 

Prevention  of  Non-delivery  Notification 

A (N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E (S) 

E (S) 

Probe 

A (N) 

N/A 

Receipt  Notification 

A (N) 

A (N) 

Reply  Request  Indication 

A (N) 

E (S) 

Replying  IP-message  Indication 

E (S) 

E (S) 

Return  of  Contents 

A (N) 

N/A 

Sensitivity  Indication 

A (N) 

E (S) 

Subject  Indication 

E (S) 

E (S) 

A local  facility  subject  to  qualifiers  in  Appendix  A. 
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13.3.2  X.400  Protocol  Definitions 


13.3.2.1  Introduction 


This  section  reflects  the  agreements  of  the  NBS/OSI  Workshop  regarding  PI  and 
P2  protocol  elements. 

13.3. 2.1.1  Protocol  Classification 


The  protocol  classifications  are  defined: 

1.  UNSUPPORTED  = X 

These  elements  may  be  generated,  but  no  specific  processing  should  be  expected 
in  a relaying  or  delivering  domain.  A relaying  domain  must  at  least  relay  the 
semantics  of  the  element.  The  absence  of  these  elements  should  not  be 
assumed,  in  a relaying  or  delivering  domain,  to  convey  any  significance. 

2.  SUPPORTED  = H 

These  elements  may  be  generated.  However,  implementations  are  not  required  to 
be  able  to  generate  these  elements.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

3.  GENERATABLE  = G 

Implementations  must  be  able  to  generate  and  handle  these  protocol  elements, 
although  they  are  not  necessarily  present  in  all  messages  generated  by 
implementations  of  this  profile.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

4.  REQUIRED  = R 

Implementations  of  this  profile  must  always  generate  this  protocol  element. 
However,  its  absence  cannot  be  regarded  as  a protocol  violation  as  other  MHS 
implementations  may  not  require  this  protocol  element.  Appropriate  actions 
shall  be  taken  in  a relaying  or  delivering  domain. 

5.  MANDATORY  = M 

This  must  occur  in  each  message  as  per  X.411  or  X.420  as  appropriate;  absence 
is  a protocol  violation.  Appropriate  actions  shall  be  taken  in  a relaying  or 
delivering  domain. 
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13.3.2.1.2  General  Statements  on  Pragmatic  Constraints 


o Where  a protocol  element  is  defined  as  a choice  of  Numeric 
String  and  Printable  String  (i.e.,  Country  Name,  Administration 
Domain  Name  and  Private  Domain  Identifier),  then  a numeric  value 
encoded  as  a printable  string  is  equivalent  to  the  same  value 
encoded  as  a numeric  string. 

o The  maximum  number  of  recipients  in  a single  MPDU  is  32K  - 1 
(that  is,  32767).  However,  no  individual  limits  on  the  number 
of  occurrences  (recipients)  are  placed  on  the  following  protocol 
elements:  Authorizing  Users,  Primary  Recipients,  Copy 

Recipients,  Blind  Copy  Recipients,  Obsoletes  and  Cross 
References.  Additionally,  there  is  no  limit  on  the  number  of 
Reply  to  Users.  This  is  a local  matter  for  the  originating 
system. 

o Use  of  strings.  A Printable  String  is  defined  in  terms  of  the 
number  of  characters,  which  is  the  same  number  of  octets.  For 
T.61  strings  the  number  of  octets  is  twice  the  number  of 
characters  specified. 

o The  ability  to  generate  maximum  size  elements  is  not  required, 
with  the  exception  of  the  component  fields  in  the  Standard 
Attribute  List,  in  which  case  it  is  required. 

13.3.2.1.3  MPDU  Size 

The  following  agreements  govern  the  size  of  MPDUs: 

o All  MTAEs  must  support  at  least  one  MPDU  of  at  least  one 
megabyte. 

o The  size  of  the  largest  MPDU  supported  by  a UAE  is  a local  matter. 
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13.3.2.2  PI  Protocol  Elements 


13.3.2.2.1  PI  Envelope  Protocol  Elements 

Table  13.3.7  contains  Protocol  Elements  and  their  classes. 

Tbl.  13.3.7  PI  protocol  elements 


Element 

Class 

Restrictions  and  Comments 

MPDU 

UserMPDU 

G 

DeliveryReportMPDU 

G 

ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

M 

UMPDUContent 

M 

UMPDUEnvelope 

MPDUIdentif ier 

M 

originator  ORname 

M 

originalEncodedlnformationTypes  G 

If  this  field  is  absent,  then  the 

Encoded  Information  Type  is 

"unspecified" . 

ContentType 

M 

UAContentID 

H 

Maximum  length  = 16  characters. 

Priority 

G 

PerMessageFlag 

G 

Maximum  length  = 2 octets. 

deferredDelivery 

X 

PerDomainBilaterallnfo 

X 

No  limit  on  number  of  occurrences. 

Recipientlnfo 

M 

Maximum  number  = 32K  - 1 occurr- 
ences. More  severe  limitations  are 
by  bilateral  agreement. 

Tracelnformation 

M 

UMPDUContent 

M 

MPDUI den t i f i er 

GlobalDomainldentif ier 

M 

IA5String 

M 

Maximum  length  = 32  characters, 
graphical  subset  only.  Refer  to 
T.50  for  clarification  of  graphical 

PerMessageFlag 

subset. 

discloseRecipients 

H 

conversionProhibited 

G 

alternateRecipientAllowed 

H 

contentRetumRequest 

X 

(Continued  on  next  page.) 
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Tbl.  13.3.7  PI  protocol  elements,  Continued 


Element 

Class 

Restrictions  and  Comments 

PerDomainBilaterallnfo 

Count ryName 

M 

Maximum  length  = 3 characters. 

AdministrationDomainName 

M 

Maximum  length  = 16  characters. 

Bilaterallnfo 

M 

Maximum  depth  = 8;  maximum 
length  = 1024  octets 
(including  encoding). 

Recipientlnfo 

recipient 

M 

Maximum  value  = 32K  - 1 (32767). 

Extens ionldent if ier 

M 

perRec ip ientF lag 

M 

Maximum  length  = 2 octets. 

ExplicitConversion 

X 

perRec ip ientF lag 

ResponsibilityFlag 

H 

ReportRequest 

M 

UserReportRequest 

M 

Tracelnf ormation 

Reference  should  be  made  to 
Version  3 of  the  X.400  Imple- 

• 

mentor's  Guide  for  information 

Globa IDoma ini dent if ier 

M 

related  to  Trace  sequencing. 

DomainSuppliedlnfo 

M 

Doma inSupp 1 iedlnf o 

arrival 

M 

deferred 

X 

action 

M 

converted 

H 

previous 

X 

ORName 

See  section  13.3.2.2.2. 

EncodedlnformationTypes 

bit  string 

M 

Delivery  can  only  occur  if  match 
is  made  with  Registered  Encoded 
Information  Types.  Individual 
vendors  may  impose  limits. 
Maximum  length  ■ 3 octets. 

G3NonBasicParameters 

X 

TeletexNonBasicParameters 

X 

PresentationCapabilities 

X 

DeliveryReportMPDU 

DeliveryReportEnvelope 

M 

DeliveryReportContent 

M 
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Tbl.  13.3.7  PI  protocol  elements.  Continued 


Element 

Class 

Restrictions  and  Comments 

DeliveryReportEnvelope 

report 

M 

originator  ORname 

M 

Tracelnformation 

M 

DeliveryReportContent 

original 

M 

intermediate 

G 

UAContentID 

G 

ReportedRecipientlnfo 

M 

Maximum  number  = 32K  - 1 
occurrences . 

returned 

H 

Can  only  be  issued  if  specifically 
requested  in  the  originating 
message. 

billinglnf ormation 

X 

Maximum  depth  = 8;  maximum 
length  = 1024  octets  (including 
encoding) . 

ReportedRecipientlnfo 

recipient 

M 

Extensionsldentif ier 

M 

PerRecipientFlag 

M 

Las tTracelnf ormation 

M 

intendedRecipient 

H 

Supplementarylnf ormation 

X 

Maximum  length  = 64  characters. 

Note:  This  length  is  subject  to 

change.  Value  is  pending 
verification  by  the  CCITT  SG 
VIII  or  IX. 

LastTracelnf ormation 

arrival 

M 

converted 

H 

Report 

M 

Report 

Deliveredlnfo 

G 

Generated  if  delivery  is  reported. 

NonDeliveredlnfo 

G 

Generated  if  failure  to  deliver 
is  reported. 

(Continued  on  next  page.) 
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Tbl.  13.3.7  PI  protocol  elements,  continued 


Element  Class 


Deliveredlnfo 

delivery  M 

typeofUA  R 

NonDeliveredlnfo 

ReasonCode  M 

DiagnosticCode  H 

ProbeEnvelope 

probe  M 

originator  M 

ContentType  M 

UAContentID  H 

original  G 


Tracelnformation  M 

PerMessageFlag  G 

contentLength  H 

PerDomainBilaterallnfo  X 

Recipientlnfo  M 

GlobalDomainldentif ier 

CountryName  M 

AdministrationDomainName  (4)  M 

PrivateDomainldentif ier  R 


Restrictions  and  Comments 


This  element  must  be  generated  with 
a PRIVATE  value  by  PRMDs. 


Whenever  possible,  use  a meaningful 
diagnostic  code. 


Maximum  length  =16  characters. 

If  this  field  is  absent,  then  the 
Encoded  Information  Type  is 
"unspecified" . 


Maximum  number  = 32K  - 1 
occurrences . 

Maximum  length  = 3 characters. 
Maximum  length  = 16  characters  or 
digits. 

Maximum  length  = 16  characters  or 
digits.  This  element  must  be 
generated  by  PRMDs. 


End  of  Definitions 


13.3 .2.2.2  ORName  Protocol  Elements 


Only  form  1 variant  1 0/R  names  are  supported. 

Table  13.3.8  contains  ORName  protocol  elements. 

Tbl.  13.3.8  ORName  protocol  elements 


Element 

Class 

Restrictions  and  Comments 

ORName 

StandardAttributeList 

M 

DomainDef inedAttributeList 

X 

StandardAttributeList  (1) 

CountryName 

R 

As  defined  in  X.411,  Maximum 
length  = 3 characters. 

AdministrationDomainName  (4) 

R 

Maximum  length  = 16  characters 
or  digits. 

X121Address 

X 

Maximum  length  = 15  digits. 

TerminallD 

X 

Maximum  length  = 24  characters. 

PrivateDomainName  (2) 

G 

Maximum  length  = 16  characters. 

OrganizationName  (2) 

G 

Maximum  length  = 64  characters. 

Un i queUAI dent i f i er 

X 

Maximum  length  = 32  digits. 

PersonalName 

G 

Maximum  length  of  values  of  sub- 
elements  = 64  characters. 

Note:  The  possibility  that  this 

value  may  be  reduced  to  40 
characters  is  for  further 
study  by  the  CCITT. 

OrganizationalUnit  (3) 

G 

Maximum  length  = 32  characters  per 
occurrence.  A maximum  of  four 
occurrences  are  allowed. 

DomainDef inedAttributeList  (5) 

Maximum  = 4 occurrences. 

type 

M 

Maximum  length  = 8 characters. 

value 

M 

Maximum  length  = 128  characters. 

PersonalName 

surName 

M 

Maximum  length  = 40  characters. 

givenName 

G 

Maximum  length  = 16  characters. 

initials 

G 

Maximum  length  = 5 characters; 

excluding  surname  initial  and 
punctuation  and  spaces. 

generationQualif ier 

G 

Maximum  length  = 3 characters. 

(Continued  on  next  page.) 
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Tbl.  13.3.8  ORName  Protocol  Elements,  Continued 


Notes : 

1.  The  following  apply  for  comparison  of  the  Standard  Attributes  of 
an  0/R  Name: 

a.  Lower  case  is  interpreted  as  upper  case  (for  IA5). 

b.  Multiple  spaces  may  be  interpreted  as  a single  space. 
Originating  domains  shall  only  transmit  single 
significant  spaces.  If  multiple  spaces  are  transmitted, 
non-delivery  may  occur. 

2.  At  least  one  of  these  must  be  supplied. 

3.  These  should  be  sent  in  ascending  sequence,  from  the  least 
significant  COrganizational  Unit>  (lowest  in  organization 
hierarchy)  to  the  most  significant.  Only  those  specified  should 
be  sent.  (That  is,  an  unspecified  COrganizational  Unit>  should 
not  be  sent  along  as  a field  of  [null]  content,  nor  zero  length, 
etc. ) 

4.  This  attribute  shall  contain  one  space  in  all  ORNames  of 
messages  originated  in  a PRMD  that  is  not  connected  to  an  ADMD, 
and  in  ORNames  of  recipients  reachable  only  through  a PRMD; 
otherwise,  this  attribute  shall  contain  an  appropriate  ADMD 
name. 

5.  Many  existing  mail  systems  require  attributes  not  present  in 
these  agreements.  Domain  Defined  Attributes  are  a method  of 
providing  these.  Failure  to  support  the  specification  of  DDAs 
may  prevent  successful  interworking  with  such  existing  mail 
systems  until  such  time  as  all  mail  systems  are  capable  of 
supporting  delivery  via  the  standard  attribute  list  only. 
Specific  recommendations  on  the  use  of  DDAs  are  in  the 
Recommended  Practices  section. 
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13.3.2.3  P2  Protocol  Profile  (Based  on  [X.420]) 


Tables  13.3.9  and  13.3.10  classify  the  support  for  the  P2  protocol  elements 
required  by  this  profile.  The  tables  give  restrictions  and  comments  in 
addition  to  [X.420]. 

Restriction  on  length  is  one  of  the  types  of  restrictions.  The  reaction  of 
implementations  to  a violation  of  this  restriction  is  not  defined  by  this 
profile. 


13.3.2.3.1  P2  Protocol  - Heading 

Table  13.3.9  below  specifies  the  support  for  protocol  elements  in  P2  Headings. 
Tbl.  13.3.9  P2  heading  protocol  elements 


Element 

Class 

Restrictions  and  Comments 

UAPDU 

IM- UAPDU 

G 

SR-UAPDU 

X 

IM- UAPDU 

Heading 

M 

Body 

M 

Heading 

IPMessageld 

M 

originator  ORname 

R 

author izingUsers 

H 

pr imaryRec ip ients 

G 

At  least  one  of  primaryRecip ients. 

copyRecipients 

G 

copyRecipients,  or 

blindCopyRecipients 

H 

blindCopyRecipients  must  be 
present . 

inReplyTo 

G 

obsoletes 

H 

crossReferences 

H 

subject 

G 

Maximum  length  = 256  octets;  the 

expiryDate 

H 

ability  to  generate  the  maximum 
size  subject  is  not  required. 

replyBy 

H 

replyToUsers 

H 

importance 

H 

Appropriate  action  is  for  further 

sensitivity 

H 

study. 

Appropriate  action  is  for  further 

autof orwarded 

H 

study. 

(Continued  on  next  page.) 
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Tbl.  13.3.9  P2  heading  protocol  elements,  continued 


Element 

Class 

Restrictions  and  Comments 

IPmessageld 

QRName 

H 

PrintableString 

M 

Maximum  length  = 64  characters. 

ORDescriptor 

ORName 

H 

Specify  the  ORName  whenever  it  is 
possible.  See  Appendix  B. 

freeformName 

H 

Maximum  length  = 64  characters, 
graphical  subset  only  (128  octets.) 

telephoneNumber 

X 

Maximum  length  = 32  characters. 

This  allows  for  punctuation.  It 
does  not  take  into  account  possible 
future  use  by  ISDN. 

Recipient 

M 

ORDescriptor 

M 

reportRequest 

X 

replyRequest 

H 

Body 

No  limit  on  number  of  BodyParts. 

BodyPart 

G 

No  limit  on  length  of  any  BodyPart 
or  the  depth  of  ForwardedIPMessage 
BodyParts  nested.  Classification  is 

subject  to  pending  CCITT  resolution 

SR-UAPBU 

nonReceipt 

H 

receipt 

H 

reported 

M 

actualRecipient 

R 

intendedRecipient 

H 

converted 

X 

NonReceiptlnformation 

reason 

M 

nonReceiptQualif ier 

H 

comments 

H 

Maximum  length  ■ 256  characters. 

returned 

H 

May  only  be  issued  if  specifically 
requested  by  originator. 

(Continued  on  next  page.) 
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Tbl.  13.3.9  P2  heading  protocol  elements,  continued 


Element 


Class  Restrictions  and  Comments 


Receiptlnformation 

receipt  M 

typeOfReceipt  H 

Supplementary Information  X Maximum  length  = 64  characters. 

Note:  This  value  is  pending 

verification  by  the  CCITT  SG 
VIII  or  IX. 

End  of  Definitions 


13.3.2.3.2  P2  Protocol  - BodyParts 

All  BodyParts  with  identifiers  in  the  range  0 up  to  and  including  16K  -1 
are  legal  and  should  be  relayed.  BodyPart  identifiers  corresponding  to  X.121 
Country  Codes  should  be  interpreted  as  described  in  section  13.4.3.2.1. 

13.3.2.3.2.1  Privately  Defined  BodyParts 

This  section  describes  an  interim  means  for  identifying  privately  defined 
BodyParts.  This  section  shall  be  replaced  in  a future  edition  taking  into 
account  CCITT  recommendations  with  equivalent  functionality. 

BodyPart  : : = CHOICE 

[0]  IMPLICIT  IA5Text , 

[ 1 ]  IMPLICIT  TLX, 


[234] IMPLICIT 


UKBodyParts , 


[310] IMPLICIT  USABodyParts , 


] 

Where  UKBodyParts  and  USABodyParts  are  defined  as: 

SEQUENCE  BodyPartNumber , ANY 
BodyPartNumber  ::=  INTEGER 

In  the  EncodedlnformationTypes  of  the  PI  Envelope,  the  undefined  bit  must 
be  set  when  a message  contains  a privately  defined  BodyPart.  Each  UA  that 
expects  such  BodyParts  should  include  undefined  in  the  set  of  deliverable 
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EncodedlnformationTypes  it  registers  with  the  MTA. 

All  BodyPartNumbers  assigned  must  be  interpreted  relative  to  the  BodyPart 
in  which  they  are  used,  which  is  that  tagged  with  the  value  [310]  for 
those  defined  within  the  United  States.  The  NBS  assigns  unique  message 
BodyPartNumbers  for  privately  defined  formats  within  the  United  States. 

Implementations  are  required  to  generate  and  image  IA5Text. 

Implementations  should  specify  the  other  BodyPart  types  supported. 

If  an  implementation  supports  a particular  BodyPart  type  for  reception,  it 
should  also  be  able  to  support  that  BodyPart  type  for  reception  if  this  is 
part  of  a ForwardedIPMessage. 

For  the  BodyPart  types  currently  considered,  support  for  the  protocol  elements 
is  as  indicated  in  table  13.3.10. 


98 


13.3.2.3.2.2  P2  BodyPart  Protocol  Elements 


Tbl.  13.3.10  P2  BodyParts 


Elements 

Class 

Restrictions  and  Comments 

BodyPart 

IA5Text 

G 

TLX 

X 

Voice 

X 

G3Fax 

X 

TIFO 

X 

TTX 

X 

Videotex 

X 

Nat ionallyDef ined 

X 

Encrypted 

X 

ForwardedIPMessage 

H 

SFD 

X 

TIF1 

X 

IA5Text 

repertoire 

H 

IA5String 

M 

For  rendition  of  IA5Text  see 
Appendix  C. 

TLX 

For  further  study  by  CCITT. 

Voice 

Set 

For  further  study  by  CCITT. 

BitString 

M 

G3Fax 

numberOfPages 

X 

G3NonBasicParameters 

X 

SEQUENCE  (OF  BIT  STRING) 

M 

BIT  STRING 

H 

See  Note. 

G3NonBas icParameters 

Support  for  individual  elements  is 
for  further  study. 

TIFO 

T. 73Document 

M 

T. 73ProtocolElement 

H 

See  Note. 

(Continued  on  next  page.) 


99 


Tbl.  13.3.10  P2  BodyParts,  continued 


Elements 

Class 

Restrictions 

and  Comments 

TTX 

numberOf Pages 

X 

telexCompatible 

X 

TeletexNonBasicParams 

X 

SEQUENCE  (of  T61String) 

M 

T61String 

H 

See 

Note. 

TeletexNonBasicParams 

graphicCharacterSets 

X 

controlCharacterSets 

X 

pageFormats 

X 

miscTerminalCapabilities 

X 

privateUse 

X 

Videotex 

SET 

For 

further 

study 

by  CCITT. 

Videotexstring 

M 

NationallyDef ined 

ANY 

M 

Encrypted 

SET 

For 

further 

study 

by  CCITT. 

BIT  STRING 

M 

ForwardedIPMessage 

delivery 

H 

Delivery Information 

H 

IM-UAPDU 

M 

De 1 i very Inf ormat ion 

ContentType 

M 

originator 

M 

original 

M 

Priority 

G 

DeliveryFlags 

M 

otherRecipients 

H 

thisRecipient 

M 

intendedRec ip ient 

H 

converted 

X 

submission 

M 

(Continued  on  next  page.) 
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Tbl.  13.3.10  P2  BodyParts,  continued 


Elements 

Class 

Restrictions  and  Comments 

SFD 

SFD. Document 

M 

TIF1 

T.73  Document 

M 

Note:  This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 

It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.  A Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.  The  NBS/OSI  Workshop  will 
adopt  the  CCITT  decision. 


13.3.3  Reliable  Transfer  Server  (RTS) 


13.3.3.1  Implementation  Strategy 

Based  on  X.410  clause  3 and  X.411  clause  3.5. 

13.3.3.2  RTS  option  selection 

o The  maximum  number  of  simultaneous  associations  is  not  limited 
in  this  profile;  if  the  capacity  of  a system  is  exceeded,  it 
should  not  initiate  or  accept  additional  associations. 

o Associations  are  established  by  the  MTA  which  has  messages  to 
transfer. 

o Associations  are  released  when  they  are  not  needed. 

Associations  may  also  be  ended  prematurely  due  to  internal 
problems  of  the  RTS. 

o For  both  monologue  and  two  way  alternate  associations,  the 

initiator  keeps  the  initial  turn. 

When  establishing  an  RTS  association,  the  following  rules  apply  to  the  use  of 

parameters  in  addition  to  those  in  X.410  clause  3.2.1: 

Dialogue  mode:  Monologue  must  be  supported  for  this 

profile;  two-way  alternate  is  used  only 
if  both  partners  agree. 

Initial  turn:  Kept  by  the  initiator  of  the  association. 

The  'priority-mechanism*  and  the  ' transfer-time  limit'  are  regarded  as  local 
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matters . 


13.3.3.3  RTS  Protocol  Options  and  Clarifications 

Realization  of  the  RTS  protocol  is  subject  to  the  following  rules  in  addition 
to  those  specified  in  X.410  clause  4: 

1.  One  RTS  association  corresponds  to  one  or  more  consecutive 
session  connections  (not  concurrent  ones).  The  first  is  opened 
with  Connect ionData  of  type  OPEN,  and  subsequent  ones  are  opened 
with  type  RECOVER. 

2.  Recovery  of  a Session  connection  is  only  by  RTS  initiator. 

3.  Checkpoint  size: 

o Checkpointing  and  No  Checkpointing  should  be  supported. 

Whenever  possible,  checkpointing  should  be  used. 

o The  minimum  checkpoints ize  is  1 (that  is,  1024  octets). 

4.  Window  size: 

o Minimal  value  of  1 (if  checkpointing  is  supported). 

d WindowSize  = 1 means:  After  an  S-SYNCH-MINOR  request  is 

sent,  wait  until  the  confirmation  is  received  before 
issuing  an  S-DATA,  S-SYNCH-MINOR,  or  S- ACTIVITY -END 
request. 

5.  APDUs  should  not  be  blocked  into  one  activity. 

6.  Only  one  SSDU  shall  be  transferred: 

o Between  two  adjacent  minor  synch  points. 

o Between  minor  synch  points  and  adjacent  S-ACTIVITY-START 
and  S -ACTIVITY-END  requests. 

o Between  S-ACTIVITY-START  and  S- ACTIVITY -END  without 
checkpoints. 
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7.  A monologue  association  is  defined  as  follows: 

o The  RTS  user  responsible  for  establishing  the  association 
is  called  the  initiator. 

o The  initiator  keeps  the  initial  turn. 

o APDUs  are  transferred  in  the  direction  of  the  initiator 
to  the  recipient  only. 

o There  shall  be  no  token  passing. 

o Only  the  initiator  can  effect  an  orderly  release  of  the 
association. 

8.  A two-way  alternate  session  is  as  described  in  X.410. 


9.  In  the  UserData  parameter  of  the  S-TJ- ABORT,  the 

ReflectedParameter  will  not  be  used  in  the  Abortlnf ormation 
element. 

10.  When  the  S -ACTIVITY-RESUME  is  used  to  resume  an  activity  in  the 
same  session  connection  as  the  one  in  which  it  started,  this 
must  happen  immediately  after  the  activity  has  been  interrupted 
(i.e.,  no  intervening  activity  can  occur).  Otherwise,  [X.410 
clause  4.3  paragraph  1]  may  be  violated. 

11.  When  S -ACTIVITY-RESUME  is  used  to  resume  an  activity  started  in 
another  session  connection,  the  following  conditions  must  be 
met: 

o The  current  session  connection  is  of  type  "recover". 

o The  value  of  OldSessionConnectionldentif ier  in 
S -ACTIVITY-RESUME  must  match  the  value  of  the 
SessionConnectionldentif ier  parameter  used  in  the  S- 
CONNECT  of  the  prior  session  connection.  This  value  is 
also  identical  to  the  SessionConnectionldentif ier  in  the 
Connect ionData  (in  PConnect,  in  SS-UserData)  for  the 
current  session  connection. 

o This  must  occur  as  the  first  activity  of  the  next 

session  connection  for  the  same  RTS-association.  It 
must  be  the  first,  otherwise  [X.410  clause  4.5.1  point 
1]  is  violated. 

Note:  It  is  in  the  same  RTS-ASSOCIATION  because  the  use 

of  S -ACTIVITY-RESUME  only  makes  sense  within  the 
scope  of  one  RTS  association. 
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12.  If  the  transfer  of  an  APDU  is  interrupted  before  the 
confirmation  of  the  first  checkpoint,  the  value  of  the 
SynchronizationPointSerialNumber  in  S -ACTIVITY-RESUME  should  be 
zero,  and  the  S- ACTIVITY -RESUME  must  be  immediately  followed  by 
an  S -ACTIVITY-DISCARD. 

13.  In  S- TOKEN -PLEASE,  the  UserData  parameter  shall  contain  an 
integer  conforming  to  X.409  which  conveys  the  priority. 

14.  The  receiving  RTS  can  use  the  value  of  the  Reason  parameter  in 
the  S-U-EXCEPTION-REPORT  to  suggest  to  the  sending  RTS  that  it 
should  either  interrupt  or  discard  the  current  activity. 

As  stated  in  Version  3 of  the  X.400  Series  Implementor's  Guide, 
"On  receipt  of  an  ' unrecoverable  procedure  error'  the  current 
activity  is  not  recoverable  and  the  sending  RTS  issues  an  S- 
ACTIVITY-DISCARD.  On  receipt  of  any  other  reason  code  (including 
a nonspecific  error),  the  sending  RTS  issues  an 
S -ACTIVITY -INTERRUPT  followed  by  an  S - ACTIVITY -RESUME. " 

15.  In  the  case  of  S-P-ABORT,  the  current  activity  (if  any)  is 
regarded  as  interrupted,  rather  than  discarded. 

16.  The  following  table  illustrates  the  legal  negotiation 
possibilities  allowed  by  X.410  clause  4.2.1  regarding  checkpoint 
size  and  window  size. 
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Tbl.  13.3.11  Checkpoint  window  size  of  IP 


acceptor  answer 

CS  = 0 

(or  unspecified) 
WS  unspecified 

CS  = m 
WS  = j 

(or  unspecified) 

CS  - n 
WS  = j 

(or  unspecified) 

initiator 

proposal 

CS  = 0 

(or  unspecif ied) 
WS  = i 

(or  unspecified) 

legal 

legal 

legal 

CS  = k 
WS  = i 

(or  unspecified) 

legal 

legal 

not  allowed 

Legend: 

o CS  means  Checkpoints ize 
o WS  means  WindowSize 

o i,  j,  k,  o,  and  n are  integer  values  with  the  following  relations: 

0 < m < k < n (values  assigned  to  CS) 

0 < j < i (values  assigned  to  WS) 

o For  unspecified  parameters,  the  default  applies.  In  this  case, 
the  numeric  relations  apply,  that  is,  the  default  values  substitute 
for  the  unspecified  integer. 
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13.3.3.4  RTS  Protocol  Limitations 


The  RTS  Protocol  Limitations  for  this  profile  are  listed  in  table  13.3.12. 

Tbl.  13.3.12  RTS  protocol  elements 


Element  Class 

Restriction 

PConnect 

H 

DataTransferSyntax 

M 

Value  = 0. 

pUserData 

M 

checkpoints ize 

H 

windowSize 

H 

dialogueMode 

H 

Connect ionData 

M 

applicationProtocol 

R 

Value  = 1 . 

Connect ionData 

open 

G 

recover 

G 

open 

RTS  user  data 

G 

recover 

SessionConnectionldentif ier 

G 

RTS  user  data 

mTAWame 

G 

Maximum  length  32  characters 
graphic  subset  of  IA5  only. 

password 

G 

Maximum  length  64  octets 
graphic  subset  of  IA5  only. 

< null  RTS  User  Data  > 

G 

Generated  if  other  validation 
methods  are  used. 

SessionConnectionldentif ier 

CallingSSUserReference 

M 

Maximum  length  64  octets  including 
encoding  = 62  octets  of  T.61. 

CommonReference 

M 

AdditionalReferencelnformation 

G 

Maximum  length  4 octets  including 
encoding  = 2 octets  of  T.61. 

PAccept 

G 

DataTransferSyntax 

M 

Value  = 0. 

pUserData 

M 

checkpoints ize 

H 

windowSize 

H 

Connect ionData 

G 

(Continued  on  next  page.) 
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Tbl.  13.3.12  RTS  protocol  elements,  continued 


Element 

Class 

Restriction 

PRefuse 

G 

RefuseReason 

M 

SS  User  Data 

G 

(in  S- TOKEN- PLEASE) 

Abortlnformation 

G 

(in  S-U -ABORT) 

AbortReason 

H 

ref lec t edPar ameter 

X 

Restricted  to  8 bits. 

End  of  Definitions 

13.3.4  Use  of  Session  Services 


The  session  requirements  and  use  of  session  are  covered  in  section  8 of  this 
document. 

13.3.5  Data  Transfer  Syntax 

This  section  defines  Presentation  Transfer  Syntax  and  notation  rules 
applicable  to  these  agreements.  Implementations  must  conform  EXACTLY  as 
specified  in  X.409  with  no  further  restrictions.  Appendix  C defines  rendition 
of  IA5  Text  and  T61  characters. 

13.4  PRMD  to  ADMD  and  ADMD  to  ADMD 


13.4.1  Introduction 


This  section  defines  the  implementation  agreements  that  apply  to  the  interface 
between  two  management  domains  when  at  least  one  is  an  ADMD.  A message 
arriving  at  an  ADMD  has  either  no  recipient  within  that  domain  or  one  or  more 
recipients  within  that  domain.  In  the  former  case,  the  ADMD  serves  as  a relay 
between  two  or  more  domains  and  the  actions  required  of  that  ADMD  are 
independent  of  the  nature  (PRMD  or  ADMD)  of  the  domains.  In  the  latter  case, 
the  ADMD  is  responsible  for  delivering  messages  to  the  proper  recipient(s) 
within  its  jurisdiction,  and  may  also  be  responsible  for  relaying  the  message. 

Given  the  two  roles  for  an  ADMD,  this  section  describes  two  distinct  sets  of 
functional  requirements  for  an  ADMD.  The  first  is  the  relaying  requirement 
that  is  needed  to  provide  PRMD  and  other  ADMD  interworking.  The  second  is 
analogous  to  the  PRMD's  support  to  its  customers  through  the  integrated  UAs. 
These  are  distinct  functional  differences.  The  services  provided  to  the  UAs 
of  an  ADMD  are  independent  of  the  requirement  that  an  ADMD  provide  a function 
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for  interworking  with  any  type  of  Management  Domain  (MD).  Figure  13.4.1 
illustrates  the  two  roles  played  by  an  ADMD. 
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This  section  is  presented  in  the  form  of  deviations  from  the  agreements 
applicable  to  PRMD-to-PRMD  (section  13.3.0).  Unless  explicitly  noted  in  the 
remainder  of  this  section,  all  of  the  specifications  for  PRMD  to  PRMD  apply  to 
PRMD  to  ADMD  and  ADMD  to  ADMD. 


PRMD  or  ADMD 

I PM  - UA 

/«. 

MTA 

\ 

-P2- 

-PI- 


ADMD 

/ 

I PM  - UA 

MTA 

(a) 


/N 

i 

i 

i 

i 

i 

PI 

i 

i 

i 

i 

i 

i 


PRMD  or  ADMD 

PRMD  or  ADMD 

I PM  - UA 

/ 

I PM  - UA 

V 

MTA 

MTA 

A\ 

l 

l 

l 

I 

I 

PI 

I 

l 

I 

l 

l 

l 


(b) 


Fig.  13.4.1  An  ADMD  may  (b)  or  may  not  (a)  serve  as  a relay. 
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13.4.2  Additional  ADMD  Functionality 


The  following  defines  the  additional  ADHD  specific  functionality  required  over 
and  above  that  specified  in  the  PRMD  section. 

1.  ADMDs  will  relay  all  content  types  (not  just  P2)  unchanged  in  the 
absence  of  a request  for  conversion. 

2.  PI  Protocol  Classification  Changes 

The  following  describes  the  changes  to  the  PRMD  PI  Protocol 
classifications  required  for  a delivering  Administration  Domain  (with 
respect  to  the  original  message;  this  means  the  domain  which 
originates  the  delivery  reports). 

Protocol  Elements  Class 

DeliveryReportContent 

intermediate  Tracelnformation  G See  note  1. 

Deliveredlnfo 
typeOfUA 

ReportedRecipientlnfo 

Supplementary Informat ion 

GlobalDomainldentif ier 
PrivateDomainldentif ier 

DomainSuppliedlnfo 

Previous  GlobalDomainldentif ier  H Required  for  loop  detection. 

For  relaying  administration  domains,  the  clasif ications  are  all  "X". 

For  originating  administration  domains,  these  are  all  "NOT  APPLICABLE". 

Note  1:  If  the  intermediate  trace  information  is  requested  by  a domain  other 
than  the  originating  domain,  return  of  the  desired  information  cannot  be 
assured,  as  the  return  path  of  the  delivery  report  may  be  different  from  the 
original  message  and  may  exclude  that  domain. 

Note  2:  Domains  providing  access  to  TELEX/ TELETEX  recipients,  whether 

directly  or  indirectly  as  a result  of  bilateral  agreements  between  domains, 
must  ensure  that  this  information,  when  present,  is  accessible  by  the 
recipient  of  the  delivery  report. 

3,  0/R  Names 

0/R  Names  shall  consist  of: 


H 

H See  note  2. 
H 
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CountryName 

AdministrationDomainName 

as  well  as  one  of  the  following: 

PrivateDomainName 

PersonalName 

OrganizationName 

OrganizationalUnit 

Un i queUAI dent i f i er 

X121Address 

and  permits  the  optional  inclusion  of  a 
DomainDef inedAttributeList 

Note  that  the  destination  PrivateDomainName  or  OrganizationName  must 
be  present  if  destined  for  a PRMD.  The  ADMD  relaying  the  message  to 
that  destination  PRMD  requires  this  element. 

PI  Originator  Name 

Management  Domains  (MDs)  must  specify  in  the  ADMD  name  field  of  the  Q/R 
Name  StandardAttributeList  in  PI,  the  name  of  the  administration  domain: 

o to  which  the  message  is  being  sent  (in  recipient  names) 

o from  which  the  message  originated  (in  the  originator  name). 


13.4.3  Interworking  with  Integrated  UAs 

If  the  message  originates  at  a UA  owned  by  an  ADMD,  or  is  delivered  to  such  a 
UA,  the  0/R  Name  follows  the  same  Form  1 Variant  1 constraints  as  the  base 
specifications;  except  that  the  ADMD  name  is  the  name  of  the  ADMD  that  owns 
the  UA  and  instead  of  supplying  a PRMD  Name,  one  (or  more)  of  the  following 
must  be  provided: 

OrganizationName 

OrganizationalUnit 

PersonalName 

and  may  optionally  include  a 

DomainDef inedAttributeList 

13.4.4  Differences  with  other  Prof iles 


13.4.4.1  NTT  Profile 


There  are  no  outstanding  issues  regarding  interworking  between  NTT-conformant 
systems  and  NBS- conformant  systems  with  the  exception  of  the  number  of 
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recipients.  The  Extensionldentif ier  field  may  contain  a maximum  value  of 
32K-1;  however,  according  to  the  current  NTT  profile,  if  a message  with  more 
than  256  recipients  is  received,  the  NTT-conformant  domain  will  generate  a 
nondelivery  notification.  This  also  applies  to  the  ReportedRecipientlnfo  in  a 
delivery  report. 

13.4.4.2  CEPT  Profile 


For  further  study. 

13.4.5  Connection  of  PRMDs  to  Multiple  ADMDs 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be  unique  within 
the  U.S.,  then  when  an  ADMD  is  presented  a message  for  transfer  from  a PRMD, 
it  will  accept  0/R  Names  (both  originator  and  recipient)  which  have  an 
AdministrationDomainName  field  value  different  than  the  administration's  name. 
"Accept"  implies  the  attempt  to  route/ deliver  the  message  shall  be  made,  as 
appropriate,  based  upon  the  knowledge  that  MD  names  are  unique. 

Whether  this  functionality  is  required  by  an  administration  for  conformance  to 
this  agreement  is  for  further  study. 

If  a PRMD  is  connected  to  two  or  more  ADMDs  which  are  not  effectively 
connected  (either  directly  or  via  a third  ADMD),  full  X.400  functionality 
shall  not  be  available.  Problems  occur  especially  in  the  areas  of: 

o Naming 
o Routing 
o Replying. 

13.4.6  Connection  of  an  ADMD  to  a Routing  PRMD 

It  is  possible  for  a collection  of  interconnected  private  domains  to  establish 
one  domain  as  the  "gateway"  to  an  ADMD,  and  hence  to  the  world. 

If  an  ADMD  is  connected  to  such  a gateway  PRMD,  the  individual  private  domains 
shall  be  registered  with  the  administration.  Administrations  need  not  support 
such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a message  originating  somewhere 
within  the  PRMD  collection,  that  the  Tracelnformation  may  contain  more  than 
one  element. 

13.4.7  Management  Domain  Names 

All  Management  Domain  Names  (both  Private  and  Administration)  shall  be  unique 
within  the  U.S. 

A central  naming  authority  shall  be  established  to  register  domain  names. 

13.4.8  Envelope  Validation  Errors 
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For  validation  errors,  a non-delivery  notice  shall  be  generated  (if  possible) 
with  reason  code  of  'unableToTransfer ' and  diagnostic  code  of 
' invalidParameters 1 (unless  specified  otherwise). 

ADMDs  will  validate  PI  Envelopes  in  the  following  areas: 

o The  X.409  syntax  of  all  elements  should  be  checked. 

o The  pragmatic  constraint  limits  (lengths  of  fields  and  number  of 
occurrences  of  fields)  should  be  checked. 

o Semantic  validation  of  the  following  elements  should  be  done: 

originator  0/R  Name 

recipient  0/R  Name  in  the  Recipientlnfo 
priority 

Only  recipient  Names  with  the  responsibility  flag  set  should  be 
validated.  The  validation  of  0/R  names  is  defined  in  13.5.3.3;  the 
validation  of  priority  is  defined  in  13.5.3.6.1. 

o MPDU  Identifier  Validation 

Validation  of  the  GlobalDomainldentif ier  component  of  the  MPDU  Identifier 
is  performaed  upon  reception  of  a message  (i.e.,  as  a result  of  a 
TRANSFER. Indication) . 

The  country  name  should  be  known  to  the  validating  domain,  and  depending 
on  the  country  name,  validation  of  the  ADMD  name  may  also  be  possible. 

Additional  validation  of  the  GlobalDomainldentif ier  is  performed  against 
the  corresponding  first  entry  in  the  Tracelnformation.  If 
inconsistencies  are  found  during  the  comparison,  a non-delivery  notice 
with  the  above  defined  reason  and  diagnostic  codes  is  generated. 

A request  will  be  generated  to  the  CCITT  for  a more  meaningful  diagnostic 
code  (such  as  ' InconsistentMPDUIdentif ier 1 ) . 


13.4.9  Quality  of  Service 

13.4.9.1  Domain  Availability 

13.4.9.1.1  ADMD  Availability 

The  goal  is  to  provide  24  hour  per  day  availability.  Note  that  there  will  be 
periods  of  time  when  an  ADMD  may  be  unavailable  due  to  maintenance  windows  in 
its  supporting  network  or  in  an  MTA  within  the  domain. 

13.4.9.1.2  PRMD  Availability 

Although  the  goal  of  PRMD  availability  is  also  24  hours  per  day,  business 
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reasons  are  likely  to  dictate  some  different  level  of  availability.  ADMDs 
shall  require  a profile  from  the  PRMD  that  indicates  its  schedule  of  regular 
availability  to  the  ADMD. 

13.4.9.2  Delivery  Times 

In  the  absence  of  standardized  quality  of  service  parameters,  the  following 
are  agreed  to.  When  standardized  parameters  from  CCITT  Study  Group  I become 
available,  they  shall  be  adopted. 

The  following  delivery  time  targets  are  established: 

Delivery  Class  95%  Delivered  Before 

Urgent  3/4  hour 

Normal  4 hours 

Non-Urgent  24  hours 

The  interval(s)  between  retries  and  the  number  of  retry  attempts  that  an  ADMD 

uses  in  attempting  delivery  to  a PRMD  or  integrated  UA,  will  be  locally 
determined  domain  parameters.  However,  the  total  elapsed  times  after  which 
delivery  attempts  will  be  stopped  are  as  follows.  This  implies  that,  after 
these  times,  a Non-Delivery  Notice  will  be  generated. 

Delivery  Class  NonDelivery  Forced  After 

Urgent  4 hours 

Normal  24  hours 

Non-Urgent  36  hours 

Both  tables  apply  to  the  period  between  acceptance  by  the  originating  MTA  in 
the  originating  administration  domain  to  the  time  of  delivery  in  the 
destination  adminstration  domain.  Transit  time  within  PRMDs  in  NOT  included 
in  the  above  times. 

13.4.10  Billing  Information 

All  aspects  relating  to  billing,  charging,  tariffs,  and  settlement,  and  in 
particular  to  the  use  of  the  billinglnformation  field  in  the  delivery  report, 
is  subject  to  bilateral  agreement,  and  shall  not  be  addressed  in  these 
implementation  agreements. 

No  ADMD  shall  require  a PRMD  to  supply  or  process  billing  information. 

13.4.11  Transparency 

No  PI  extensions  are  to  be  allowed.  Should  an  ADMD  receive  a message 
containing  PI  extensions,  it  shall  generate  a non-delivery  notice  (if 
possible)  with  reason  code  of  unableToTransf er  and  diagnostic  code  of 
invalidParameters . 

The  CCITT  has  been  requested  to  establish  a more  meaningful  diagnostic  code 
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(such  as  protocolError ) for  this  occurrence. 

P2  extensions  shall  be  relayed  transparently  by  ADMDs. 

13.4.12  For  Further  Study 

Issues  requiring  further  study  are: 

o RTS  Password  Management 
o Intra-Domain  Routing 
o Multi -Vendor  Domains 

13.5  ERROR  REPORTING 


This  section  describes  appropriate  actions  to  be  taken  upon  receipt  of 
protocol  elements  which  are  not  supported  in  this  profile,  malformed  MPDUs, 
unrecognized  0/R  Name  forms,  content  errors,  errors  in  reports,  and 
unexpected  values  for  protocol  elements. 

13.5.1  MPDU  Encoding 

The  MPDU  should  have  a context-specific  tag  of  0,  1,  or  2.  If  it  does  not 
have  one  of  these  tags,  it  is  not  possible  to  figure  out  who  originated  the 
message.  Therefore,  the  way  this  error  is  reported  is  a local  matter. 

13.5.2  Contents 

Once  delivery  to  the  UA  has  occurred,  it  is  not  possible  to  report  errors  in 
P2  information  to  the  originator.  In  addition,  it  seems  unreasonable  to 
insist  that  the  MTA  that  delivers  a message  ensures  that  the  P2  content  of  the 
message  is  okay.  As  a result,  the  handling  of  content  errors  is  a local 
matter . 

13.5.3  Envelope 

13.5.3.1  Pragmatic  Constraint  Violations 

In  all  cases  of  pragmatic  constraint  violation,  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  unableToTransfer , and  a DiagnosticCode  of 
invalidParameters . Note:  it  would  be  desirable  for  the  CCITT  to  add  a 
DiagnosticCode  of  pragmaticConstraintViolation  to  allow  a more  meaningful 
description  of  this  problem.  A request  for  this  new  DiagnosticCode  has  been 
submitted. 


13.5.3.2  Protocol  Violations 


If  not  all  required  protocol  elements  are  present,  a nondelivery  report  with  a 
ReasonCode  of  unableToTransfer  and  a DiagnosticCode  of  invalidParameters 
should  be  generated.  Note:  it  would  be  desirable  for  the  CCITT  to  add  a 
DiagnosticCode  of  protocolViolation  to  allow  a more  meaningful  description  of 
this  problem.  A request  for  this  new  DiagonsticCode  has  been  submitted. 
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If  a protocol  element  is  expected  to  be  of  one  type,  but  is  encoded  as 
another,  then  a nondelivery  report  with  a ReasonCode  of  unableToTransfer  and  a 
DiagnosticCode  of  invalidParameters  should  be  generated.  Note:  it  would  be 
desirable  for  the  CCITT  to  add  a DiagnosticCode  of  protocolViolation  to  allow 
a more  meaningful  description  of  this  problem.  A request  for  this  new 
DiagnosticCode  has  been  submitted. 

13.5.3.3  Q/R  Names 


The  domain  that  has  responsibility  for  delivering  a message  should  also  have 
the  responsibility  to  send  the  nondelivery  notification  if  the  message  cannot 
be  delivered.  Therefore,  each  domain  should  only  validate  the  0/R  Names  of 
recipients  with  responsibility  flags  set  to  TRUE.  In  addition,  a nondelivery 
notification  can  only  be  sent  if  the  originator's  0/R  Name  is  valid. 

If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the  CountryName, 
AdministrationDomainName,  and  one  of  PrivateDomainName  and  OrganizationName 
(and,  for  ADMDs,  PersonalName  and  OrganizationalUnit ) are  not  all  present, 
then  a nondelivery  report  should  be  generated  with  a ReasonCode  of 
unableToTransfer,  and  a DiagnosticCode  of  unrecognizedORName.  If  the  message 
can  be  delivered  even  though  the  ORName  is  invalid,  delivery  is  a local 
matter.  Note,  however,  that  if  the  message  is  delivered,  the  invalid  ORName 
might  be  propagated  through  the  X.400  system  (e.g.,  by  forwarding). 

If  the  0/R  Name  has  all  of  the  appropriate  protocol  elements  and  the  message 
still  cannot  be  delivered  to  the  recipient,  the  following  DiagnosticCodes  may 
appear  in  the  nondelivery  report:  unrecognizedORName,  ambiguousORName,  and 
uaUnavailable. 

13.5.3.4  Tracelnf ormat ion 


Since  non-relaying  domains  need  not  do  loop  suppression,  domains  with 
responsibility  for  delivering  the  message  need  not  be  concerned  about  the 
semantics  of  the  Tracelnf ormat ion,  that  is,  arrival  time  and  converted 
EncodedlnformationTypes  can  be  provided  to  the  UA  without  inspection  by  the 
MTAs  of  the  domain  as  long  as  the  Tracelnformation  is  properly  encoded 
according  to  X.409. 

Loop  detection  in  a relaying  domain  occurs  as  a message  leaves  a domain.  If 
the  subsequent  domain  already  appears  in  the  Trace  Information  and  does  not 
appear  in  a "previous"  field  of  a trace  information  element  with  a "rerouted" 
indication,  a loop  has  occurred.  A non-delivery  notice  should  be  generated 
with  reason  code  of  'unableToTransfer'  and  diagnostic  code  of  ' loopDetected ' . 

CCITT  Study  Group  VII  will  address  this  in  its  October  1986  meeting. 

Note  that  a domain  may  insert  several  instances  of  Trace  information  into  a 
message.  The  first  must  be  a "relayed"  indication.  Additional  entries  shall 
only  be  of  type  "rerouted"  and  must  contain  the  "previous" 
GlobalDomainldentif ier . The  "previous"  field  indicates  that  domain  to  which 
delivery  was  previously  attempted  (and  not,  as  might  be  inferred  from  the 
name,  the  domain  which  relayed  the  message  prior  to  this  relaying  domain).  If 
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this  is  not  the  case,  a non-delivery  notice  shall  be  returned  with  a reason 
code  of  'unableToTransfer 1 and  a diagnostic  code  of  ' invalidParameters 1 . 

A request  shall  be  made  to  CCITT  for  a more  meaningful  diagnostic  code  (such 
as  ' invalidTracelnf ormation 1 ) . 

13.5.3.5  Unsupported  X.400  Protocol  Elements 

The  protocol  elements  defined  in  X.400  but  unsupported  by  this  profile  are: 
the  deferredDelivery  and  PerDomainBilaterallnfo  parameters  of  the 
UMPDUEnvelope,  the  ExplicitConversion  parameter  of  Recipientlnfo,  and  the 
alternateRecipientAllowed  and  contentReturnRequest  bits  of  the  PerMessageFlag . 
Appropriate  actions  are  described  below  for  domains  that  do  not  support  the 
protocol  elements. 

13.5.3.5.1  deferredDelivery 

The  domain  shall  do  one  of  the  following: 

o deliver  at  once, 
o hold  for  deferred  delivery, 

o return  a nondelivery  notification  with  a ReasonCode  of 
unableToTransfer . 

Note:  It  would  be  desirable  for  the  CCITT  to  add  a diagnostic  code  of 

noBilateralAgreement  to  allow  a more  meaningful  description  of  this 
problem.  A request  for  this  new  diagnostic  code  has  been  submitted. 

13. 5. 3. 5 .2  PerDomainBilaterallnfo 

If  a domain  receives  this  service  element,  the  service  element  can  be  ignored, 
and  the  message  should  be  delivered  if  possible. 

13.5.3.5.3  ExplicitConversion 

If  ExplicitConversion  is  requested  the  message  should  be  delivered  if 
possible.  That  is,  if  the  UA  is  registered  to  accept  the 

EncodedlnformationTypes  of  the  message,  then  the  message  should  be  delivered 
even  though  the  domain  could  not  perform  the  requested  conversion.  If 
delivery  is  not  possible,  then  a nondelivery  report  should  be  generated  with  a 
ReasonCode  of  conversionNotPerformed  with  no  DiagnosticCode. 

13.5.3.5.4  alternateRecipientAllowed 

If  a domain  receives  this  service  element  the  service  element  can  be  ignored, 
and  this  message  should  be  delivered  if  possible. 

13.5.3.5.5  contentReturnRequest 

If  a domain  receives  this  service  element,  the  service  element  can  be  ignored, 
and  the  message  should  be  delivered  if  possible. 
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13.5.3.6  Unexpected  Values  for  INTEGER  Protocol  Elements 


There  are  three  INTEGERS  in  the  PI  Envelope.  Appropriate  actions  are 
described  below  for  domains  receiving  unexpected  values  for  Priority, 
ExplicitConversion,  and  ContentType. 

13.5.3.6.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at  least  one  group  of 
implementors  as  upward  compatible  changes  to  the  X.400  Recommendations. 
Therefore,  if  a domain  receives  an  unexpected  value  for  Priority,  and  this 
value  is  greater  than  one  byte  in  length,  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  unableToTransfer  and  DiagnosticCode  of 
invalidParameters.  If  the  value  is  less  than  or  equal  to  one  byte,  the  domain 
can  either  generate  a nondelivery  report  as  previously  specified  or  default 
the  Priority  to  normal  and  deliver  the  message. 

13.5.3.6.2  ExplicitConversion 

The  message  should  be  delivered  if  possible.  That  is,  if  the  UA  is  registered 
to  accept  the  EncodedlnformationTypes  of  the  message,  then  the  message  should 
be  delivered  even  though  the  domain  could  not  perform  the  requested 
conversion.  If  delivery  is  not  possible,  then  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  conversionNotPerf ormed  with  no  DiagnosticCode. 

13.5.3.6.3  ContentType 

If  the  ContentType  is  not  supported,  then  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  unableToTransfer,  and  a DiagnosticCode  of 
invalidParameters.  Note:  it  would  be  desirable  for  the  CGITT  to  add  a 
DiagnosticCode  of  contentTypeNotSupported  to  allow  a more  meaningful 
description  of  this  problem.  A request  for  this  new  DiagnosticCode  has  been 
submitted. 


13.5.3.7  Additional  Service  Elements 


In  the  absence  of  bilateral  agreements  to  the  contrary,  receipt  of  privately 
tagged  elements  and  protocol  elements  in  addition  to  those  defined  in  X.400 
will  result  in  a nondelivery  report  with  a ReasonCode  of  unableToTransfer  and 
a DiagnosticCode  of  invalidParameters. 

13.5.4  Reports 

There  is  no  mechanism  for  returning  a delivery  or  status  report  due  to  errors 
in  the  report  itself.  Therefore  the  handling  of  errors  in  reports  is  a local 
matter . 

13.6  MHS  USE  OF  DIRECTORY  SERVICES 

Recommendation  X.400  recognizes  the  need  of  MHS  users  for  a number  of 
directory  service  elements.  Directory  service  elements  are  intended  to  assist 
users  and  their  UAs  in  obtaining  information  to  be  used  in  submitting  messages 
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for  delivery  by  the  MTS.  The  MTS  may  also  use  directory  service  elements  to 

obtain  information  to  be  used  in  routing  messages.  Some  functional 

requirements  of  directories  have  been  identified  and  are  listed  below. 

o Verify  the  existence  of  an  0/R  name. 

o Return  the  0/R  address  that  corresponds  to  the  0/R  name  presented, 
o Determine  whether  the  0/R  name  presented  denotes  a user  or  a 
distribution  list. 

o Return  a list  of  the  members  of  a distribution  list. 

o When  given  a partial  name,  return  a list  of  0/R  name  possibilities. 

o Allow  users  to  scan  directory  entries. 

o Allow  users  to  scan  directory  entries  selectively. 

o Return  the  capabilities  of  the  entity  referred  to  by  the  0/R  name. 

o Provide  maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a number  of  operational  aspects  must  be 
considered.  These  include  user-friendliness,  flexibility,  availability, 
expandability,  and  reliability. 

Currently,  these  aspects  of  directory  service  elements  and  procedures  are 
under  study  by  both  the  CCITT  and  the  ISO.  Both  organizations  are  committed 
to  the  development  of  a single  Directory  Service  specification  for  use  by  MHS 
and  all  other  OSI  based  applications. 

Given  the  incomplete  nature  of  the  ongoing  activities  within  the  CCITT  and  the 
ISO,  no  implementation  details  will  be  provided  now  for  MHS  use  of  Directory 
Services.  Implementation  agreements  for  MHS  Use  of  Directory  Services  will  be 
issued  when  current  activities  within  the  CCITT  and  the  ISO  are  stable. 

It  is  recognized  that  these  agreements  enable  a wide  variety  of  naming  and 
addressing  attributes  (see  section  13.3.5.3.3  ORName  Protocol  Elements) 
wherein  each  PRMD  may  adopt  particular  routing  schemes  within  its  domain. 
These  agreements  make  no  attempt  to  recommend  a standard  practice  for 
electronic  mail  addressing. 

Inter-PRMD  addressing  may  be  secured  according  to  practices  outside  the  scope 
of  these  agreements,  such  as: 

o manual  directories 
o on-line  directories 
o ORName  address  specifications 
o ORName  address  translation. 

Further,  each  PRMD  may  adopt  naming  and  addressing  schemes  wherein  the  user 
view  may  take  a form  entirely  different  from  the  attributes  reflected  in 
section  13.3.4.2.2  herein.  And,  each  PRMD  may  have  one  user  view  for  the 
originator  form  and  another  for  the  recipient  form,  and  perhaps  other  forms  of 
user  addressing.  In  some  cases  (e.g.,  receipt  notification)  these  user  forms 
must  be  preserved  within  the  constraints  of  these  implementation  agreements. 
However,  mapping  between  one  PRMD  user  form  to  another  PRMD  user  form,  via  the 
X.400  ORName  attributes  of  these  agreements,  is  outside  the  scope  of  these 
agreements . 
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13.7  CONFORMANCE 


In  order  to  ensure  that  products  conform  to  these  implementation  agreements, 
it  is  necessary  to  define  the  types  and  degrees  of  conformance  testing 
products  that  must  pass  before  they  may  be  classified  as  conformant.  This 
section  defines  the  conformance  requirements  and  provides  guidelines  for  the 
interpretation  of  the  results  from  this  type  of  testing. 

In  order  to  achieve  a minimum  level  of  confidence  in  the  conformance  of  a 
product,  the  most  basic  requirements  a product  must  meet  to  be  classified  as 
conformant  to  these  agreements  are  provided.  This  minimal  set  was  defined  to 
ensure  that  the  resulting  MHS  network  will  provide  a reasonable  inter- 
personal messaging  facility  to  its  users  while  still  giving  a reasonable 
assurance  that  conforming  products  can  soon  be  made  available.  In  addition, 
the  full  conformance  requirements  for  products  implementing  all  aspects  of 
X.400  Messaging  governed  by  these  agreements  are  provided. 

This  section  is  incomplete  and  will  be  enhanced  in  future  versions  of  this 
agreement.  Later  versions  will  reflect  the  problems  of  conformance  testing 
and  will  outline  specific  practices  and  recommendations  to  aid  the  development 
of  conformance  tests  and  procedures. 

13 .7.1  Definition  of  Conformance 


For  this  section,  the  term  conformance  is  defined  by  the  following: 

o The  tests  indicated  for  this  section  are  intended  to  establish  a 
high  degree  of  confidence  in  a statement  that  the  implementation 
under  test  (IUT)  conforms  (or  does  not  conform)  to  the 
agreements  of  this  section. 

o Conformance  to  a service  element  means  that  the  information 

associated  with  the  service  element  is  made  accessible  to  the 
user  (person  or  process)  whenever  this  agreement  says  that  this 
information  should  be  available. 

Accessible  means  that  information  must  be  provided  describing 
how  a user  (person  or  process): 

o causes  appropriate  information  to  be  displayed,  or 

o causes  appropriate  information  to  be  obtained. 

o Conformance  to  PI,  P2,  and  RTS  as  part  of  an  X.400  OSI 

application  requires  that  only  the  external  behavior  of  that  OSI 
system  adheres  to  the  relevant  protocol  standards. 

In  order  to  achieve  conformance  to  this  section,  it  is  not 
required  that  the  inter-layer  interfaces  be  available  for 
testing  purposes. 
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o 


Conformance  to  the  protocols  requires: 


o that  MPDUs  correspond  to  instances  of  syntactically  correct 
data  units, 

o MPDUs  in  which  the  data  present  in  the  fields  and  the 

presence  (or  absence)  of  those  fields  is  valid  in  type  and 
semantics  as  defined  in  X.400,  as  qualified  by  this  profile, 

correct  sequences  of  protocol  data  units  in  responses 
(resulting  from  protocol  procedures). 

o Statements  regarding  the  conformance  of  any  one  implementation 

to  this  profile  are  not  complete  unless  a Protocol 

Implementation  Conformance  Statement  (PICS)  is  supplied. 

o The  term  "Implementation  Under  Test"  (IUT)  is  interchangeable 
with  the  term  "system"  in  the  definition  of  conformance,  and 
may  refer  to: 

o a domain,  which  may  be  one  or  more  MTA's  with  co-located  or 
remote  UA's, 

o a single  instance  of  an  MTA  and  co-located  UA  with  X.400 
(PI,  P2,  RTS  and  session)  software, 

o a relaying  product  with  PI,  RTS  and  session  software, 

o a gateway  product. 

o Tests  for  conformance  apply  independently  to: 

o origination, 
o reception, 
o relaying. 

13.7.2  Conformance  Requirements 

Conformance  to  this  specification  requires  that  all  the  services  listed  as 
supported  in  sections  13.3  and  13.4  of  these  agreements  are  supported  in  the 
manner  defined,  in  either  the  CCITT  X.400  Recommendations  or  these  agreements. 

It  is  the  intention  to  adopt,  where  and  when  appropriate  the  testing 
methodology  and/or  the  abstract  test  scenarios  currently  being  defined  by  the 
CCITT  X.400  Conformance  Group.  However  it  is  recognized  that  formal  CCITT 
Recommendations  relating  to  X.400  Conformance  Testing  will  not  be  available 
until  1988. 

13.7.2.1  Initial  Conformance 
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This  section  is  intended  to  provide  guidelines  to  vendors  who  envisage  having 
X.400  products  available  prior  to  any  formal  mechanism,  or  'Conformance  Test 
Center'  being  made  accessible  that  would  allow  for  conformance  to  this  product 
specification  to  be  tested. 

It  is  feasible  that  vendors  and  carriers  will  want  to  enter  bilateral  test 
agreements  that  will  allow  for  initial  trials  to  be  carried  out  for  the 
purposes  of  testing  initial  interworking  capabilities.  It  is  equally  feasible 
that  for  purposes  of  testing  interoperability,  only  a subset  of  this 
specification  will  initially  be  tested.  Therefore  it  is  recommended  that  the 
following  subset  of  total  information  be  made  accessible  to  allow  for 
meaningful  testing. 

Note:  By  claiming  conformance  to  this  subset  of  information  the  vendor 

or  carrier  cannot  claim  conformance  to  this  entire  specification. 

There  are  two  aspects  to  the  requirements,  interworking  and  service,  as 
described  in  the  following  sections. 

13.7.2.1.1  Interworking 

The  interworking  requirements  for  conformance  implies  that  tests  be  done  to 
check  for  the  syntax  and  semantics  of  protocol  data  elements  for  a system  as 
defined  by  their  classifications  (i.e.,  X,  H,  G,  R,  and  M).  For  an  origination 
system,  this  implies  that  the  protocol  elements  generated  must  be  correct. 
For  a relay  system,  the  correct  protocol  elements  should  be  relayed  as 
appropriate.  And  for  a recipient  system,  a message  with  correct  protocol 
elements  must  not  be  rejected  where  appropriate. 

13.7.2.1.2  Service 


For  information  available  to  the  recipients  via  the  IPMessage  Heading  and 
Body,  the  following  should  be  made  accessible: 

o IPMessage  ID  - only  the  PrintableString  portion  of  the  IPMessageld 
needs  to  be  accessible. 

o subject 

o primaryRecipients 
o copyRecipients 
o blindCopyRecipients 
o author izingUsers 
o originator 
o inReplyTo 
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o replyToUsers 
o importance 
o sensitivity 


o IA5Text  BodyPart 


14.  DIRECTORY  SERVICES  PROTOCOLS 


To  be  competed. 


124 


15.  VIRTUAL  TERMINAL  PROTOCOL 


To  be  completed. 
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16.  OFFICE  DOCUMENT  ARCHITECTURE  AND  INTERCHANGE  FORMAT 


To  be  completed. 
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17.  PERFORMANCE 


To  be  completed. 
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18.  SECURITY 


To  be  completed. 
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APPENDIX  A:  INTERPRETATION  OF  SERVICE  ELEMENTS 


The  work  on  service  element  definitions  is  limited  to  those  that  are  defined 
as  'supported'  in  section  13.3  of  this  specification.  Furthermore  it  is  not 
the  intent  of  this  section  to  define  how  information  should  be  made  available 
or  presented  to  a MHS  user,  nor  is  it  intended  to  define  how  individual 
vendors  should  design  their  products.  In  addition,  statements  on  conformance 
to  a specific  service  element  and  the  allocation  of  error  codes  that  are 
generated  as  a result  of  violations  of  the  service  should  be  defined  in  the 
sections  on  conformance  and  errors  as  part  of  the  main  product  specification. 
The  main  objective  is  to  provide  clarification,  where  required,  on  the 
functions  of  a service  element,  and  in  particular  what  the  original  intent  of 
the  Recommendations  were. 

SERVICE  ELEMENTS 

The  following  Service  Elements  defined  in  X.400  have  been  examined  and  require 
further  text  to  be  added  to  their  definitions  to  represent  the  proposed 
implementation  of  these  service  elements  by  the  X.400  SIG. 

The  service  element  clarifications  are  to  be  taken  in  the  context  of  this 
profile. 

Service  elements  not  referenced  in  this  section  are  as  defined  in  X.400. 

PROBE 

A PRMD  need  not  generate  probes. 

If  a probe  is  addressed  to  and  received  by  a PRMD,  the  PRMD  must  respond  with 
a Delivery  Report  as  appropriate  at  the  time  the  probe  was  processed. 

DEFERRED  DELIVERY 

In  the  absence  of  bilateral  agreements  to  the  contrary,  Deferred  Delivery  and 
Deferred  Delivery  Cancellation  are  local  matters  (i.e.,  confined  to  the 
originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the  initiating 
domain  is  via  bilateral  agreement  as  specified  in  Section  3.4.2. 1 of  X.411. 

Content  Type  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to 
support  P2  content  type.  The  ability  for  domains  to  be  able  to  exchange 
content  types  other  than  P2  will  depend  on  the  existence  of  bilateral  or 
multi-lateral  agreements. 
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Original  Encoded  Information  Types  Indication 


It  is  required  that  both  an  originating  and  recipient  domain  be  able  to 
support  IA5  text.  Support  for  other  encoded  information  types,  for  the 
purposes  of  message  transfer  between  domains,  will  depend  on  the  existence  of 
bilateral  or  multi-lateral  agreements. 

The  use  of  the  'unspecified'  form  of  encoded  information  type  should  only  be 
used  when  the  UMPDU  content  represents  an  SR-UAPDU  or  contains  an  auto- 
forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a message  is  not  meaningful  unless  a 
message  is  converted  en  route  to  the  recipient.  These  agreements  support  only 
IA5  text,  which  should  not  undergo  conversion.  The  original  encoded 
information  types  should  be  made  accessible  to  the  recipient  for  upward 
compatibility  with  the  use  of  non-IA5  text  message  body  parts. 

Registered  Encoded  Information  Types 

A UMPDU  with  an  'unspecif ied'  value  for  Original  Encoded  Information  Type 
shall  be  delivered  to  the  UA. 

Delivery  Notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification  for 
correlation  purposes. 

Disclosure  of  Other  Recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but  must  be 
supported  by  relaying  and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient  can  be 
informed  of  the  0/R  names  of  the  other  recipient(s)  of  the  message,  as  defined 
in  the  PI  envelope,  in  addition  to  the  0/R  Descriptors  within  the  P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other  recipients, 
but  the  information  associated  with  it  should  be  made  accessible  to  the 
recipient  for  upward  compatibility  with  support  for  the  initiation  of  this 
service  element. 

Typed  Body 

As  defined  in  X.400  with  the  addition  of  the  Private  Body  Types  that  are  to  be 
supported.  At  present  there  is  no  mechanism  provided  within  X.420  that  would 
allow  you  to  respond  to  reception  of  an  unsupported  body  type. 

Action  taken  in  this  situation  is  a local  matter. 

Blind  Copy  Recipient  Indication 
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It  should  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the 
recipient,  and  therefore  may  choose  to  disclose  all  BCC  recipients  to  each 
other.  Therefore  it  is  the  responsibility  of  the  originating  domain  to  submit 
two  or  more  messages,  depending  on  whether  or  not  each  BCC  should  be  disclosed 
to  each  other  BCC. 


Auto  Forwarded  Indication 


A UA  may  choose  not  to  forward  a message  that  was  previously  auto- forwarded. 
In  addition  there  is  no  requirement  for  an  IPM  UA  that  does  not  support 
non-receipt  or  receipt  notification  to  respond  with  a non-receipt  notification 
when  a message  is  auto- forwarded. 

Primary  and  Copy  Recipients  Indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however,  for 
a forwarded  message  this  need  not  be  present.  The  recipient  UA  should  be 
prepared  to  accept  no  primary  and  copy  recipients  to  enable  future 
interworking  with  Teletex,  Fax,  etc. 

Sensitivity  Indication 

A message  originator  should  make  no  assumptions  as  to  the  semantic 
interpretation  by  the  recipients  UA  regarding  classifications  of  sensitivity. 
For  example,  a personal  message  may  be  printed  on  a shared  printer. 

Reply  Request  Indication 

In  requesting  this  service  an  originator  may  additionally  supply  a date  by 
which  the  reply  should  be  sent  and  a list  of  the  intended  recipients  of  the 
reply.  If  no  such  list  is  provided  then  the  initiator  of  the  reply  sends  the 
reply  to  the  originator  of  the  message  and  any  recipients  the  reply  initiator 
wishes  to  include.  The  replytoUsers  and  the  replyBy  date  may  be  specified 
without  any  explicit  reply  being  requested.  This  may  be  interpreted  by  the 
recipient  as  an  implicit  reply  request.  Note  that  for  an  auto- forwarded 
message  an  explicit  or  implicit  reply  request  may  not  be  meaningful. 

Body  Part  Encryption 

The  original  encoded  information  type  indication  includes  the  encoded 
information  type(s)  of  message  body  parts  prior  to  encryption  by  the 
originating  domain.  The  ability  for  the  recipient  domain  to  decode  an 
encrypted  body  part  is  a local  matter.  Successful  use  of  this  facility  can 
only  be  guaranteed  if  there  exists  bilateral  agreements  to  support  the 
exchange  of  encrypted  body  parts. 

Forwarded  IP  message  Indication 

The  following  use  of  the  original  encoded  information  type  in  the  context 
of  forwarded  messages  is  clarified: 
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o 


If  forwarding  a private  message  body  part  the  originator  of  the 
forwarded  message  shall  set  the  original  encoded  information 
types  in  the  PI  envelope  to  undefined  for  that  body  part. 


o The  encoded  information  types  of  the  message  being  forwarded 
should  be  reflected  in  the  new  original  encoded  information 
types  being  generated. 

o See  Appendix  B on  recommended  practices  for  the  use  of  the 
delivery  information  as  part  of  Forwarded  IP-message. 

Multipart  Body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and  meaningful 
structuring  of  a message  that  is  constructed  using  differing  body  part  types. 
For  example,  it  is  not  recommended  that  a message  made  up  of  only  IA5  text 
should  be  represented  as  a number  of  IAS  body  parts,  each  one  representing  a 
paragraph  of  text. 
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APPENDIX  B:  RECOMMENDED  PRACTICES 


B.l  RECOMMENDED  PRACTICES  IN  P2 

1 . ORDescriptor 

Vendors  following  the  NBS/OSI  Workshop  guidelines  shall, 
whenever  possible,  generate  the  ORName  portion  of  an 
ORDescriptor  in  ALL  IPM  heading  fields. 

2 . ForwardedIPMessage  BodyParts 

ForwardedIPMessage  BodyParts  should  be  nested  no  deeper  than 
eight.  There  is  no  restriction  on  the  number  of 

ForwardedIPMessage  BodyParts  at  any  given  depth. 

3.  Delivery Information 

It  is  strongly  recommended  that  Delivery Information  be  supplied 
in  both  forwarded  and  autoforwarded  message  body  parts. 
Deliverylnformation  is  useful  when  a message  has  multiple 
forwarded  message  body  parts  because  without  it,  the 

EncodedlnformationType(s)  of  the  component  forwarded  messages 
cannot  be  deduced  easily.  Deliverylnformation  is  useful  for 
autoforwarded  messages  because  the  EncodedlnformationType  of  an 
autoforwarded  message  is  "unspecified"  and  the 
EncodedlnformationType(s)  of  the  message  cannot  be  determined 
easily  without  it.  Absence  of  the  EncodedlnformationType ( s ) 
makes  it  difficult  for  a UA  to  easily  determine  whether  the 
message  can  be  rendered. 


B.2  RECOMMENDED  PRACTICES  IN  RTS 

1.  In  the  case  where  S-U-ABORT  indicates  a temporaryProblem, 
reestablishment  of  the  session  should  not  be  attempted  for  a 
"sensible"  time  period  (typically  not  less  than  five  minutes). 

In  instances  where  this  delay  is  not  required  or  necessary, 
report  a localSystemProblem. 
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2.  S-U- EXCEPTION-REPORT  reason  codes  can  be  interpreted  as  follows: 


o receiving  ability  jeopardized  (value  1) 

Possible  meaning:  The  receiving  RTS  knows  of  an 

impending  system  shutdown. 

o local  ss-User  error  (value  5) 

Possible  meaning:  <for  further  study>. 

o irrecoverable  procedure  error  (value  6) 

Possible  meaning:  the  current  activity  is  NOT 

recoverable. 

o non  specific  error  (value  0) 

Possible  meaning:  <for  further  study>. 

o sequence  error  (value  3):  The  S -ACTIVITY-RESUME 

request  specified  a minor  synchronization  point  serial 
number  which  does  not  match  the  checkpoint  data. 


B. 3 RECOMMENDED  PRACTICES  WITH  X.409 

The  following  practices  are  recommended  for  use  with  X.409. 

1.  The  maximum  length  of  a primitive  data  element  is  256. 

2.  Bit  Strings  should  be  built  using  primitive  form.  The 
constructor  form  should  not  be  used  except  in  the  case  of  very 
long  Bit  Strings  (e.g.,  63Fax  or  Voice). 

3.  All  defined  bits  of  a Bit  String  should  be  present. 

o Note  that,  in  accordance  with  X.409,  defined  bits  need 
not  be  present;  missing  bits  are  assumed  to  be  zero. 

o To  ensure  upward  compatibility.  Bit  Strings  of  excess 

length  must  also  be  allowed;  the  excess  bits  are  ignored. 


4.  The  maximum  definite  length  should  be  (2**32)-l.  <For  further 
study> . 
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5.  It  is  intended  that  implementations  support  upwardly  compatible 
changes  to  X.409,  as  defined  in  Version  3 of  the  X. 400-Series 
Implementor's  Guide,  but  no  guarantees  will  be  made  about 
initial  implementations. 

6.  The  concrete  encoding  of  ANY  must  be  a valid  X.409  type,  and  can 
only  be  omitted  if  it  is  an  OPTIONAL  element  in  a SET  or 
SEQUENCE. 


B.4  RECOMMENDED  PRACTICES  FOR  ORName 

Table  13.3.8  stipulates  that  the  StandardAttributeList  must  contain  either 
PrivateDomainName  or  OrganizationName.  It  is  recommended  that,  for  both 
originator  and  recipients  in  a private  domain,  the  PrivateDomainName  field  be 
used. 

It  is  recommended  that  there  should  be  a DomainDef inedAttribute  to  be  used  in 
addresing  UAs  in  existing  mail  systems,  in  order  to  curtail  the  proliferation 
of  different  types  of  DomainDef inedAttributes  used  for  the  same  purpose.  The 
syntax  of  this  DomainDef inedAttribute  conforms  to  the  CCITT  Pragmatic 
Constraints,  and  thus  has  a maximum  value  length  of  128  octets  and  a type 
length  of  8 octets,  each  of  type  Printable  String.  Only  one  occurrence  is 
allowed i 

This  DomainDef inedAttribute  has  the  type  name  "ID"  (in  uppercase).  It 
contains  the  unique  identifier  of  the  UA  used  in  addressing  within  the  domain. 
This  DomainDef inedAttribute  is  to  be  exclusively  used  for  routing  within  the 
destination  domain  (i.e.»  once  routed  to  that  domain  via  the  mandatory 
components  of  the  StandardAttributeList);  any  other  components  of  the 
StandardAttributeList  may  be  provided.  If  they  conflict  delivery  is  not  made 


The  contents  of  this  parameter  need  not  be  validated  in  the  originating  domain 
or  any  relaying  domain,  but  simply  transferred  intact  to  the  next  MTA  or 
domain. 
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APPENDIX  C:  RENDITION  OF  IA5Text  AND  T61String  CHARACTERS 


C.l  GENERATING  AND  IMAGING  IA5Text 

The  characters  that  may  be  used  in  an  IA5String  are  the  graphic  characters 
(including  Space),  control  characters  and  Delete  of  the  IA5  character 
repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a guaranteed  rendition  are  those 
related  with  positions  2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to 
7/10  in  the  basic  7-bit  code  table. 


The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 


The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a 
subset  consisting  of  the  format  effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR) 
provided  they  are  used  in  one  of  the  following  combinations: 


CR  LF 
CR  FF 
LF  ..  LF 


to  start  a new  line 

to  start  a new  page  (and  line) 

to  show  empty  lines  (always  after  one  of  the  preceding 
combinations) . 


The  other  control  characters  or  the  above  control  characters  in  different 
combinations  may  be  used  but  have  no  guaranteed  effect. 


The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The  IA5String  in 
a P2  IA5Text  BodyPart  represents  a series  of  lines  which  may  be  divided  into 
pages . Each  line  should  contain  from  0 to  80  graphic  characters  for 
guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition. 
Note  that  X.408  states  that  for  conversion  from  IA5Text  to  Teletex,  the 
maximum  line  length  is  77  characters. 


C.2  GENERATING  AND  IMAGING  T61String 
For  further  study. 
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APPENDIX  D:  FTAM  DOCUMENT  TYPES 


Part  1 
Part  2 
Part  3 
Part  4 


Document  Types 
Constraint  Sets 
Abstract  Syntaxes 
Transfer  Syntaxes 
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Part  1 : Document  Types 


Entry  number:  NBS-1 

Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  UNDEF(O)} 

Document  Descriptor  Value:  unstructured  binary  file 

Document  Semantics: 

The  document  consists  of  a single  data  unit.  The  data  unit  consists  of  an 
unbounded  sequence  of  data  elements.  Each  data  element  is  is  an  octet  string. 
Note:  The  boundaries  between  transferred  data  elements  are  not  maintained  by 

the  filestore. 

Scope  and  Field  of  Application: 

This  document  type  defines  the  contents  of  a file  for  storage  and  for 
transfer  using  FTAM. 

Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1 ) } 

Abstract  Syntax: 

The  abstract  syntax  of  each  Data  Element  is  an  instance  of  the  ASN.l  data  type 
Octetstring. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  x825)  to  the  data  element  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting . 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 
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Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation : 

Concatenation  of  this  type  with  itself  is  possible,  and  produces  a document 
of  the  same  type  consisting  of  one  data  unit  which  is  the  concatenation  of 
the  octet  string(s)  from  one  file  with  the  octet  string(s)  of  the  other  file. 

Note:  The  boundary  of  the  original  octet  string(s)  is  no  longer  visible. 

Simplifications: 

A document  of  this  type  cannot  be  accessed  as  any  other  document  type. 
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Entry  Number:  NBS-2 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  VARCRLF(l)} 

Document  Descriptor  Value:  unstructured  text  file 

Document  Semantics: 

The  document  consists  of  a single  data  unit.  The  data  unit  consists  of  an 
unbounded  sequence  of  data  elements.  Each  data  element  is  an  IASString.  The 
last  two  characters  of  each  data  element  are  carriage  return  followed  by  line 
feed.  Neither  the  character  carriage  return  nor  the  character  line  feed  may 
appear  elsewhere  in  the  data  element. 

Note:  The  boundaries  between  transferred  data  elements  are  not  maintained  by 

the  filestore. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  transfer  using  FTAM. 

Note  that  this  document  type  should  only  be  used  for  transferring  entire  text 
files  in. the  case  where  NBS-4  is  not  supported.  It  has  an  implicit  structure 
which  allows,  for  example,  text  files  stored  in  UNIX  format  (lines  terminated 
by  LF)  to  be  converted  to  a format  in  which  lines  are  terminated  -by  CR 
followed  by  LF  and  vice  versa. 

Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1 ) } 

Abstract  Syntax: 

The  abstract  syntax  of  each  Data  Element  is  an  instance  of  the  ASN.l  data  type 
IA5String. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  element  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting. 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name; 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation: 

Concatenation  of  this  type  with  itself  is  possible,  and  produces  a document  of 
the  same  type  consisting  of  one  data  unit  which  is  the  concatenation  of  the 
octet  string(s)  from  one  file  with  the  octet  string(s)  of  the  other  file. 

Note:  The  boundary  of  the  original  octet  string(s)  is  no  longer  visible. 

Simplification: 

A document  of  this  type  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the  F- 
OPEN  request,  and  limiting  access  context  to  US  on  F-READ. 
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Entry  Number:  NBS-3 

Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  8859VARCRLF( 2) } 

Document  Descriptor  Value:  unstructured  text  file 

Document  Semantics: 

The  document  consists  of  a single  data  unit.  The  data  unit  consists  of  an 
unbounded  sequence  of  data  elements.  Each  data  element  is  an  8859String.  The 
last  two  characters  of  each  data  element  are  carriage  return  followed  by  line 
feed.  Neither  the  character  carriage  return  nor  the  character  line  feed  may 
appear  elsewhere  in  the  data  element. 

Note:  The  boundaries  between  transferred  data  elements  are  not  maintained  by 
the  filestore. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  transfer  using  FTAM. 

Note  that  this  document  type  should  only  be  used  for  transferring  entire  text 
files  in  the  case  where  NBS-5  is  not  supported.  It  has  an  implicit  structure 
which  allows,  for  example,  text  files  stored  in  UNIX  format  (lines  terminated 
by  LF)  to  be  converted  to  a format  in  which  lines  are  terminated  by  CR 
followed  by  LF  and  vice  versa. 

Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1 ) } 

Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
8859String. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting  octets. 


Note:  This  transfer  syntax  is  not  self -delimiting . 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS1  (0)} 
Concatenation : 

Concatenation  of  a document  of  this  type  with  another  document  of  this  type  is 
possible  and  produces  a document  of  the  same  type  consisting  of  one  data  unit 
which  is  the  concatenation  of  the  octetstring(s)  of  one  file  with  the 
octetstring(s)  of  the  other  file. 

Note:  The  boundary  of  the  original  Octetstring  is  no  longer  visible. 

Simplification: 

A document  of  type  NBS -3  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the  F- 
OPENrequest,  and  limiting  access  context  to  US  on  F-READ. 
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Entry  number:  NBS-4 


Document  type  name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  Text(3)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  OBJECT  IDENTIFIER. 

Document  Descriptor  Value:  Sequential  Text  File 

Document  Semantics: 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data  unit 
contains  one  data  element  which  is  a character  string.  Each  character  is 
taken  from  the  IA5  character  set. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  storage  and  for 
transfer  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  sequential  flat(2)} 

Additional  Constraints: 

FADU  Identity  will  be  limited  to  begin,  end,  first  and  next. 

Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
IA5String. 

The  abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting  octects. 

Note:  This  transfer  syntax  is  not  self -delimiting . 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation : 

Concatenation  of  a document  of  this  type  with  another  document  of  this  type  is 
possible  and  produces  a document  of  the  same  type  consisting  of  a series  of 
IA5Strings  which  is  the  result  of  placing  the  series  of  IA5Strings  from  one 
file  of  this  type  after  the  last  IA5String  in  the  original  file. 

Note:  The  boundary  of  the  original  sequence  is  no  longer  visible. 

Simplification: 

A document  of  type  NBS-4  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  on  the  F- 
OPENrequest,  and  limiting  access  context  to  UA  on  F-READ. 
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Entry  number:  NBS-5 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  8859Text(4)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the 

registered  identifier  in  an  Object  Identifier. 

Document  Descriptor  Value:  Sequential  Text  File 

Document  Semantics: 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data  unit 
contains  one  data  element  which  is  a character  string.  Each  character  is 
taken  from  the  ISO  8859/1  character  set. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  storage  and  transfer 
using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 
Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  sequential  flat (2)} 

Additional  Constraints: 

FADU  Identity  will  be  limited  to  begin,  end,  first  and  next. 

Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
8859String. 

The  abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting . 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 


Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS1  (0)} 
Concatenation : 

Concatenation  of  a document  of  this  type  with  another  document  of  this  type  is 
possible  and  produces  a document  of  the  same  type  consisting  of  a series  of 
8859Strings  which  is  the  result  of  placing  the  series  of  8859Strings  from  one 
file  immediately  following  the  last  8859String  in  the  original  file. 

Note:  The  boundary  of  the  original  series  is  no  longer  visible. 

Simplification: 

A document  of  type  NBS-5  can  be  accessed  as  a document  of  type  NBS- 1 by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  on  F- 
OPENrequest,  and  limiting  access  context  to  UA  on  F-READ. 
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Entry  Number;  NBS-6 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  SEQUENTIAL(5)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  Object  Identifier. 

Document  Descriptor  Value:  Sequential  File 

Document  Semantics: 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data  unit 
contains  an  unbounded  series  of  data  elements.  Each  data  element  is  a data 
type  from  the  set  of  primitive  data  types  defined  in  the  main  body  of  this 
document.  Each  data  unit  contains  the  same  data  element  types  in  the  same 
order  as  all  other  data  units. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  storage  and  transfer 
using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Constraint  Set  Name: 

{ISO  standard  8571  constraint  set  name(5)  sequential  flat(2)} 

Additional  Constraints: 

FADU  Identity  will  be  limited  to  begin,  end,  first,  and  next. 

Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 

The  Abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 
optionally,  {ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2) 

NBS-AS2( 1 ) } 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
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syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

(ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation : 

Concatenation  of  a document  of  this  type  with  another  document  of  this  type  is 
possible  and  produces  a document  of  the  same  type  consisting  of  a series  of 
data  units  which  is  the  result  of  placing  the  series  of  data  units  from  one 
file  immediately  following  the  last  data  unit  of  the  original  file. 

Note:  The  boundary  of  the  original  file  is  no  longer  visible. 

Simplification: 

A document  of  type  NBS-6  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  in  the  F- 
OPENrequest,  and  limiting  access  context  to  UA  on  F-READ. 
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Entrv  number:  NBS-7 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  RAND0M(6)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  Object  Identifier. 

Document  Descriptor  Value:  Random  Access  File 

Document  Semantics : 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data  unit 
contains  an  unbounded  series  of  data  elements.  Each  data  element  is  a data 
type  from  the  set  of  primitive  data  types  defined  in  the  main  body  of  this 
document.  Each  data  unit  contains  the  same  data  types  in  the  same  order  as  all 
other  data  units  in  the  file. 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  storage  and  transfer 
using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Ordered  Flat(2)} 

Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 

The  abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 
optionally,  {ISO  registration-authority  NBS  FTAM(  ) abstract  svntax(2)  NBS- 
AS2( 1 ) } 

Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  element  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting . 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation : 

Concatenation  of  a document  of  this  type  with  another  document  of  this  type  is 
possible  and  produces  a document  of  the  same  type  consisting  of  a series  of 
data  units  which  is  the  result  of  placing  the  series  of  data  units  from  one 
file  immediately  following  the  last  data  unit  of  the  original  file. 

Note:  The  boundary  of  the  original  file  is  no  longer  visible. 

Simplification: 

A document  of  type  NBS-7  can  be  accessed  as  a document  of  type  NBS-1  by 

specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the  F- 

OPENrequest,  and  limiting  access  context  to  UA  on  F-READ. 

A document  of  type  NBS-7  can  be  accessed  as  a document  of  type  NBS-6  by 

specifying  a document  type  of  NBS-6  in  the  Contents  Type  parameter  of  the  F- 

OPENrequest. 
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Entry  Number:  NBS-8 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  INDEXED(7)  pi  p2} 

Note:  "pi"  and  "p2"  are  parameters  which  will  be  appended  to  the  registered 

identifer  in  an  Object  Identifier. 

Document  Descriptor  Value:  Indexed  Sequential  File 

Document  Semantics: 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data  unit  is 
an  unbounded  series  of  data  elements.  Each  data  element  is  a data  type  from 
the  set  of  primitive  data  types  defined  in  the  main  body  of  this  document. 
Each  data  unit  contains  the  same  data  types  in  the  same  order  as  all  other 
data  units  in  the  file. 

Each  data  unit  in  the  file  has  a key  associated  with  it.  The  key  of  each  data 
unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file 
and  is  a single  data  element  from  the  set  of  primitive  data  types  defined  in 
the  main  body  of  this  document. 

The  primitive  data  types  and  minimum  size  range  of  each  unit  which  an 
implementation  must  accept  as  a key  value  are  given  in  the  following  table. 

Key  Type  Minimum  Range  (octets) 


ASN.l  General izedTime 
ASN.l  UniversalTime 
NBS-AS2  Floatingpoint 

Scope  and  Field  of  Application: 

The  document  type  defines  the  contents  of  a file  for  storage  and  for  transfer 
using  FTAM. 

Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(2) 


Abstract  Syntax: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 


ASN.l  Integer 
ANS.l  IA5String 
NBS -AS 1 8859String 
ASN.l  OctetString 


(1-2) 

(0-16) 

(0-16) 

(0-16) 


Indexed  Flat(l)} 
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The  Abstract  syntax  of  each  data  unit  is  specified  by  the  parameter  pi. 

The  Abstract  syntax  of  the  data  unit  key  (FADU  Identifier)  is  specified  by  the 
parameter  p2. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 
optionally,  {ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2) 
NBS-AS2(1)> 


Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  suport  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting  octets. 

Note:  This  transfer  syntax  is  not  self -delimiting . 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax( 3 ) NBS-TSl(O)} 
Concatenation : 

A document  of  this  type  may  not  be  concatenated  with  a document  of  this  type 
or  any  other  type. 

Simplification: 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS-1  by 

specifying  document  type  NBS-1  in  the  Contents  Type  parameter  on  the  F- 

OPENrequest,  and  limiting  access  context  to  UA  on  F-READ. 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS -6  by 

specifying  document  type  NBS-6  in  the  Contents  Type  parameter  on  the  F- 

OPENrequest. 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS- 7 bv 

specifying  document  type  NBS-7  in  the  Contents  Type  parameter  on  the  F- 

OPENrequest . 
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Entry  Number:  NBS-9 


Document  Type  Name: 

{ISO  registration-authority  NBS  FTAM(  ) document(6)  FILE_DIRECT0RY(8)} 

Document  Descriptor  Value:  FileDirectory  File 

Document  Semantics: 

The  document  consists  of  an  unbounded  sequence  of  data  units.  Each  data  unit 
consists  of  one  and  only  one  data  element  of  type  FileDirectoryEntry  (a 
complex  data  type  defined  in  the  main  body  of  this  document). 

Scope  and  Field  of  Application: 

This  document  defines  the  contents  of  a file  for  transfer  (not  for  storage) 
using  FTAM. 

Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5)  Sequential 
Flat(l)} 

Additional  Constraints: 

FileDirectory  Files  may  be  Selected,  Opened,  Read,  Closed,  Created,  and 
Deleted.  They  may  not  be  Written  or  Modified  (except  as  a side-effect  of 
actions  performed  on  individual  files  contained  within  a FileDirectory). 
DataUnits  within  a FileDirectory  may  only  be  accessed  sequentially. 

Abstract  Syntax: 

An  indefinite  series  of  data  units.  Each  data  unit  contains  one  data  element 
of  type  FileDirectoryEntry.  Each  data  element  consists  of  a required  FileName 
and  a number  of  optional  Attributes. 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(3)  f iledirectory 
entry(O) } 

Transfer  Syntax: 

An  implementation  supporting  this  data  type  shall  support  a transfer  syntax 
for  each  data  value  obtained  by  applying  ASN.l  Basic  Encoding  Rules  to  the 
data  type  FileDirectoryEntry  in  the  data  value  and  concatenating  the  resulting 
octets . 

Note:  This  transfer  syntax  is  not  self -delimiting . 
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Implementations  may  also  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concatenation: 

A document  of  this  type  cannot  be  concatenated  with  a document  of  this  type  or 
any  other  type. 

Simplification: 

A document  of  this  type  cannot  be  simplified. 
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Part  2:  Constraint  Sets 


Constaint  Set  Title:  NBS-Ordered  Flat 

Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Ordered  Flat(2)} 


Field  of  Application: 

Files  which  are  structured  into  a sequence  of 
individual  FADUs  and  to  which  access  may  be  made 
on  a FADU  basis  by  position  in  the  sequence. 

Node  Names: 

none 

Actions: 

Locate,  Read,  Replace,  Insert,  Erase 

Special  Action  Parameters: 

none 

Special  Action  Semantics: 

Erase:  Used  on  the  root  node  to  empty  the  file. 

When  used  on  a leaf  node,  it  leaves  a 
FADU  with  no  associated  data  unit. 

Insert:  Allowed  only  at  end  of  file.  The  new 

node  is  inserted  following  all  existing 
nodes  in  the  file  or  on  a leaf  node  with 
no  existing  data  unit.  The  inserted 
data  unit  is  asociated  with  the 
currently  existing  leaf  node. 

Available  Access  Contexts: 

HA,  FA,  UA,  US 

Erase  and  Locate  Context: 

HA 

Constraints  on  Structure: 

The  root  node  shall  not  have  an  associated  data 
unit.  All  children  of  the  root  node  shall  be 
leaf  nodes  and  may  have  an  associated  data  unit. 
All  arcs  from  the  root  node  shall  be  of  length 
one. 

Creation  State: 

Root  node  without  an  associated  data  unit. 

FADU  Identity: 

begin,  end,  first,  last, 
current,  next,  previous, 

traversal  number  (greater  than  or  equal  to  one) 

Location  After  Open: 

root  node 

Beginning  of  File: 

root  node 

161 


End  of  File: 


No  node  is  selected.  Previous  gives  the  last 
node  in  the  traversal  sequence,  current  and  next 
result  in  an  error. 


Constraint  Set  Title:  Indexed  Flat 

Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Indexed  Flat(l)} 


Field  of  Application: 

This  constraint  set  is  for  representing  single 
key  ISAM  files  where  the  keys  are  the  FADU 
identifiers  for  the  leaf  nodes.  The  keys  are 
restricted  to  being  single  primitive  data  types, 
and  restricted  to  all  keys  being  of  the  same 
primitive  data  type. 

Node  Names: 

Any  single  primitive  data  type. 

Actions : 

Locate,  Read,  Replace,  Insert,  Erase 

Special  Action  Parameters: 

none 

Special  Action  Semantics: 

Locate:  The  specified  FADU  is  made  the  current 

FADU.  If  the  FADU  Id  form  is  used,  the 
least  recently  inserted  FADU  with  the 
specified  FADU  at  level  1 is  located. 

Read:  Allowed  at  root  and  leaves.  If  there 

is  another  FADU  after  (in  pre-order 
traversal  order)  the  one  read  with  the 
same  FADU  Id,  a diagnostic  on 
TRANSFER_END  will  indicate  this  fact. 

Insert:  Insert  the  specified  FADU  (level  1 only) 
in  the  lexical  order  of  the  key 
primitive  data  type.  Ifthere  is  already 
another  FADU  with  the  specified  FADU  Id, 
insert  the  new  one  after  (in  pre-order 
traversal)  the  existing  FADUs  and 
indicate  that  this  was  done  via  a 
diagnostic  on  TRANSFER_END. 

Replace:  Allowed  only  at  leaves  and  only  in 
access  context  US  (DU  only  w/o 
delimiters).  Only  allowed  with  write 

operation  of  "current"  (i.e.,  preceded 
by  locate)  or  "Previous"  (i.e., 
preceded  by  read). 
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Erase: 


If  the  addressed  FADU  is  the  root,  the 
file  is  reduced  to  the  initial  state. 


Available  Access  Contexts: 
Erase  and  Locate  Context: 
Constraints  on  Structure: 

Creation  State: 

FADU  Identity: 

Location  After  Open: 
Beginning  of  File: 

End  of  File: 


HA,  FA,  UA,  US 
HA 

The  root  node  shall  not  have  an  associated  data 
unit  or/ and  FADU  Id.  All  children  of  the  root 
node  shall  be  leaf  nodes  and  shall  have  an 
associated  data  unit  and  FADU  Id.  All  arcs  from 
the  root  node  shall  be  of  length  one.  Some 
primitive  types  may  not  be  supported  as  keys. 

Root  node  without  an  associated  data  unit  or 
FADU  Id. 

begin,  end, 

current,  next,  previous, 

FADU  Id 

root  node 

root  node 

No  node  is  selected.  Previous  gives  the  last 
node  in  the  traversal  sequence,  current  and  next 
result  in  an  error. 
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Part  3:  Abstract  Syntaxes 

Abstract  Syntax:  NBS -AS 1 

Abstract  Syntax  Name; 

{ISO  registration-authority  NBS  FTAM(  ) Abstract  Syntax(2)  Basic(O)} 

Abstract  Syntax  Definition: 

DE  ::  Choice  {INTEGER, 

BOOLEAN, 

IA5String, 

8859String, 

OCTETSTRING, 

UniversalTime , 

GeneralizedTime , 

Null} 

8859String  : : = [ PRIVATE  1]  Implicit  8859CharacterString 

Transfer  syntax  name:  --  8859CharacterString  is  a string  of  characters  from 

the  ISO  8859  character  set 

{ISO  registration-authority  NBS  FTAM(  ) Transfer  Syntax(A)  NBS-TS1  (0)} 


Abstract  Syntax:  NBS-AS2 

Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  FloatingPoint( 1 ) } 

Abstract  Syntax  Definition: 

Float ingPointNumber  ::=  [PRIVATE  0]  CHOICE 

{ 

finite  [0]  IMPLICIT  SEQUENCE 

{ 

Sign, 

mantissa  BITSTRING, 
exponent  INTEGER 

}, 

infinity  [1]  IMPLICIT  Sign, 
signalling  NaN  [2]  Implicit  NaN, 
quietNaN  [3]  IMPLICIT  NaN, 
zero  [4]  IMPLICIT  NULL 

} 

Sign  ::=  INTEGER  ( {positive(O) , negative(l)} 

NaN  ::=  INTEGER 
Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
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Abstract  Syntax:  NBS -AS 3 


Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2) 

FileDirectoryElement(2)} 


Abstract  Syntax  Definition: 


FileDirectoryEntry  ::=[ PRIVATE  2]  IMPLICIT  SEQUENCE { 

fileName  Graphicstring, 
ContentsType} 


ContentsType  : : =CHOICE 

document-type-Name[0]  IMPLICIT  OBJECT  IDENTIFIER, 
constraint-set-and-abstract-syntax  [1]  IMPLICIT  SEQUENCE{ 

constraint-set-Name [ 0 ] IMPLICIT  OBJECT  IDENTIFIER, 
Abstract - syntax-Name [ 1 ] IMPLICIT  OBJECT  IDENTIFIER} 


Transfer  Syntax  Name: 

(ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
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Part  4:  Transfer  Syntaxes 


Transfer  Syntax:  NBS-TS1 

Transfer  Syntax  Name; 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 

Encoding  Rules: 

ASN.l  Basic  Encoding  Rules  shall  apply. 

The  first  bit  of  a "mantissa"  must  be  "1". 

Transfer  Syntax  Definition: 

The  transfer  syntax  shall  be  that  which  results  from  applying  the  encoding 
rules  described  above  to  the  individual  data  elements. 
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APPENDIX  E:  KNOWN  ERRORS  IN  ISO  AND  CCITT  DOCUMENTS 


This  appendix  lists  errors  that  are  known  in  ISO  and  CCITT  documents.  Known 
errors  are  removed  from  this  appendix  when  corrected  text  is  available  from 
ISO  and  CCITT.  This  appendix  is  for  information  only. 

FTAM  DIS  Errors 


Following  is  a list  of  known  errors  in  the  FTAM  DIS  which  are  expected  to  be 
corrected  in  the  forthcoming  IS.  These  errors  are  listed  here  for  information 
only  and  will  be  removed  when  the  IS  text  is  available. 

1.  The  Access  Context  parameter  on  the  F-READrequest  and  F-WRITErequest  is 
specified  as  OPTIONAL  instead  of  mandatory  in  the  FTAM  protocol  abstract 
syntax. 

The  expected  correction  is  to  make  this  parameter  mandatory. 

2.  The  Contents  Type  List  is  defined  as  a SEQUENCE  of  Document  Type  Name  and 
Constraint-Set,  Abstract-Syntax  in  the  FTAM  protocol  abstract  syntax. 

The  expected  solution  is  to  use  the  following  definition: 

Contents-Type-List  IMPLICIT  SEUENCE  OF  CHOICER 
document -types  [0]  IMPLICIT  Document-Type-Name, 
constraint-set-and-abstract-syntax[ 1 ] IMPLICIT  SEQUENCE 
constraint-sets  [0]  IMPLICIT  Constraint-Set-Name 
abstract-syntax  [1]  IMPLICIT  Abstract-Syntax-Name} 

3.  The  processing-mode  parameter  on  the  F-OPEN  request  is  not  defined 
correctly  in  the  FTAM  protocol  abstract  syntax. 

The  expected  correction  is: 

processing-mode  [0]  IMPLICIT  BITSTRING  { 

read  (0), 
insert  (1), 
replace  (2), 
erase  (3), 
extend  (4)  } 

4.  In  part  2 clause  5.3.2  the  application  tags  conflict  with  tags  in  part  4 
in  the  protocol  abstract  syntax. 

The  expected  correction  is  to  use  the  following  definitions  in  part  2 clause 
5.3.2: 


Node-Descriptor-Data-Element  ::=  [Application  21]  IMPLICIT... 
Enter-Subtree-Data-Element  ::=  [Application  22]  Implicit  Null... 
Exit-Subtree-Data- Element  ::=  [Application  23]  IMPLICIT  Null... 
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5.  An  object  identifier  for  the  CASE  protocol  abstract  syntax  is  not  defined. 
The  expected  correction  is: 

{iso  standard  8650  abstract  syntax  (1)  acse  (1)} 
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ADDENDUM  1 


Note  on  ETAM  and  X.400  Character  Sets 


On  July  21,  1986,  a group  of  twelve  individuals  from  the  FTAM  and  X.400  SIGs 
met  to  resolve  differences  in  recommended  use  of  character  sets.  The 
following  was  agreed  (in  favor,  9;  opposed,  2;  abstaining,  1)  by  these 
individuals : 

"Both  SIGs  should  implement  IA5  for  the  current  phase  of  development,  and 
independently  support  expanded  character  sets.  It  is  recommended  that  the 
FTAM  and  X.400  SIGs  support  both  8859/1  and  6937/2  in  the  next  phase  of  their 
agreements . " 

Neither  SIG  brought  forward  to  the  plenary  on  Thursday,  July  24,  1986,  a 
recommendation  on  this  issue.  However,  it  was  raised  for  plenary  discussion. 
The  plenary  felt  (in  favor,  22;  opposed,  3;  abstaining,  1)  that  this 
information  should  be  carried  in  some  form  in  this  document  in  addition  to 
inclusion  in  the  minutes.  Hence,  it  is  included  as  an  addendum  so  as  to  keep 
the  information  associated  with  this  document  while  showing  that  it  has  not 
been  accepted  for  inclusion  in  the  main  body  of  this  document. 
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You  will  receive  the  documents  from  the  next  workshop  by  either  attending  the 
workshop  or  completing  and  returning  the  form  below. 

READER  RESPONSE  FORM 


Please  retain  my  name  for  the  next  mailing  of  the  NBS/OSI  Implementors 
Workshop 

NAME  

ADDRESS  


PHONE  NO. 


Mail  this  page  to:  Mary  Lou  Fahey 

National  Bureau  of  Standards 
Bldg.  225/B217 
Gaithersburg,  MD  20899 
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